<!DOCTYPE HTML>
<html>
<head>

    <title>Plan 9 de los Laboratorios Bell</title>

    <link rel="stylesheet" href="/pub/style/style.css" type="text/css" media="screen, handheld" title="default">
    <link rel="shortcut icon" href="/favicon.ico" type="image/vnd.microsoft.icon">

    <meta charset="UTF-8">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 


<meta name="verify-v1" content="6zEoK0WMlnLmIS/w7Pnh6+srZECHsvnMGN0kQmowSGk=" />
<meta name="google-site-verification" content="z5zCyEitNLNZmhVblsogrEiy6Acf0UZROsFMtLjioN4" />
<META name="y_key" content="49dff3fad5352458"><META name="y_key" content="5dc40bfee9494e98"><META name="y_key" content="b60a53d1fa98f4c8">
<meta name="msvalidate.01" content="5008C6E6B172BEB1F43E770296C3D560" />
<meta name="alexaVerifyID" content="l1vBNiKWqe9hCZhp0jV8OKPyjps" />

    

</head>
<body>

<div id="header">
    <div class="superHeader">
    <div class="left">
      <a href="http://quotes.cat-v.org">quotes</a> |
      <a href="http://doc.cat-v.org">docs</a> |
      <a href="http://repo.cat-v.org">repo</a> |
      <a href="http://go-lang.cat-v.org">golang</a> |
      <a href="http://sam.cat-v.org">sam</a> |
      <a href="http://man.cat-v.org">man</a> |
      <a href="http://acme.cat-v.org">acme</a> |
      <a href="http://glenda.cat-v.org">Glenda</a> |
      <a href="http://ninetimes.cat-v.org">9times</a> |
      <a href="http://harmful.cat-v.org">harmful</a> |
      <a href="http://9p.cat-v.org/">9P</a> |
      <a href="http://cat-v.org">cat-v.org</a>
    </div>

    <div class="right">

      <span class="doNotDisplay">Related sites:</span>
      | <a href="http://cat-v.org/update_log">site updates</a>
      | <a href="/sitemap">site map</a> |

    <script type="text/javascript">var addthis_disable_flash = true; var addthis_pub="uriell";</script>
    <a href="http://www.addthis.com/bookmark.php?v=20" onmouseover="return addthis_open(this, '', '[URL]', '[TITLE]')" onmouseout="addthis_close()" onclick="return addthis_sendto()"><img src="http://s7.addthis.com/static/btn/lg-share-en.gif" width="125" height="16" alt="Bookmark and Share" style="border:0"/></a><script type="text/javascript" src="http://s7.addthis.com/js/200/addthis_widget.js"></script>
    </div>

    </div>

    <div class="midHeader">
    <h1 class="headerTitle"><a href="/">/sys/doc/ <span id="headerSubTitle">Documentation archive</span></a></h1>
    </div>
    
    <div class="subHeader"><br></div>
</div>

    <div id="side-bar">
        <div>
<p class="sideBarTitle">Sections:</p>
<ul>
<li><a href="/bell_labs/">&rsaquo; bell labs/</a></li>
<li><a href="/economics/">&rsaquo; economics/</a></li>
<li><a href="/henry_spencer/">&rsaquo; henry spencer/</a></li>
<li><a href="/inferno/">&rsaquo; inferno/</a></li>
<li><a href="/plan_9/" class="thisPage">&raquo;<i> plan 9/</i></a></li>
<li><ul>
<li><a href="/plan_9/1st_edition/">&rsaquo; 1st edition/</a></li>
<li><a href="/plan_9/2nd_edition/">&rsaquo; 2nd edition/</a></li>
<li><a href="/plan_9/3rd_edition/">&rsaquo; 3rd edition/</a></li>
<li><a href="/plan_9/4th_edition/">&rsaquo; 4th edition/</a></li>
<li><a href="/plan_9/IWP9/">&rsaquo; IWP9/</a></li>
<li><a href="/plan_9/blue_gene/">&rsaquo; blue gene/</a></li>
<li><a href="/plan_9/humour/">&rsaquo; humour/</a></li>
<li><a href="/plan_9/misc/">&rsaquo; misc/</a></li>
<li><a href="/plan_9/programming/">&rsaquo; programming/</a></li>
<li><a href="/plan_9/real_time/">&rsaquo; real time/</a></li>
<li><a href="/plan_9/translations/" class="thisPage">&raquo;<i> translations/</i></a></li>
<li><ul>
<li><a href="/plan_9/translations/russian/">&rsaquo; russian/</a></li>
<li><a href="/plan_9/translations/spanish/" class="thisPage">&raquo;<i> spanish/</i></a></li>
<li><ul>
<li><a href="/plan_9/translations/spanish/8">&rsaquo; 8</a></li>
<li><a href="/plan_9/translations/spanish/9" class="thisPage">&raquo;<i> 9</i></a></li>
<li><a href="/plan_9/translations/spanish/names">&rsaquo; names</a></li>
<li><a href="/plan_9/translations/spanish/net">&rsaquo; net</a></li>
</ul></li>
</ul></li>
</ul></li>
<li><a href="/political_science/">&rsaquo; political science/</a></li>
<li><a href="/programming/">&rsaquo; programming/</a></li>
<li><a href="/unix/">&rsaquo; unix/</a></li>
<li><a href="/xml/">&rsaquo; xml/</a></li>
</ul>
        </div>
        <div>
<ul>
<li><a href="http://man.cat-v.org/plan_9/">- Plan 9 Man Pages</a></li>
<li><a href="http://ninetimes.cat-v.org">- NineTimes News</a></li>
</ul>
        </div>
    </div>

<div id="main-copy">



<p style="margin-top: 0; margin-bottom: 0.50in"></p>
<p style="margin-top: 0; margin-bottom: 0.21in"></p>

<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 12pt"><b>Plan 9 de los Laboratorios Bell </b></span></p>
<p style="margin-top: 0; margin-bottom: 0.21in"></p>

<p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Rob Pike</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Dave Presotto</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Sean Dorward</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Bob Flandrena</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Ken Thompson</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Howard Trickey</i></span></p>
<p style="line-height: 1.4em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Phil Winterbottom</i></span></p>
<p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="margin-top: 0; margin-bottom: 0.08in"></p>
<p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="margin-top: 0; margin-bottom: 0.33in"></p>
<p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="margin-top: 0; margin-bottom: 0.50in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>1.
USA
</b></span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Motivación
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.50in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">A mediados de los 80, la tendencia en computación iba
alejándose de los grandes sistemas centralizados de tiempo compartido y acercándose hacia redes de maquinas personales, más pequeñas, típicamente estaciones de trabajo UNIX.
La gente estaba harta de las máquinas de tiempo compartido sobrecargadas y deseaba cambiar a sistemas pequeños, de auto-mantenimiento incluso aun perdiendo potencia de computación.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.50in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cuando los microordenadores se hicieron más rápidos, incluso esta pérdida de potencia se recuperó y este es el estilo de trabajo que permanece todavía hoy.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">En la loca carrera hacia los ordenadores personales, algunas de sus carencias fueron pasadas por alto.
Primero el sistema operativo que ejecutaban, UNIX, es realmente un sistema de tiempo compartido, y ha tenido algunos problemas para adaptarse a ideas que nacieron despues de él.
Los gráficos y las redes fueron elementos agregados sobre la marcha, y todavía permanecen como algo poco integrado y dificil de administrar.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Más importante, el enfoque inicial de tener máquinas privadas hizo dificil para las redes dar el servicio que antaño dieron los sistemas monolíticos.
Los sistemas de tiempo compartido centralizaban la gestión y amortizaban costes y recursos; la computación personal fracturó, democratizó y últimamente amplificó los problemas administrativos.
La elección de un sistema antiguo para ser ejecutado en máquinas personales dificultó las cosas. 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 nació a finales de los años 80, como un intento de tener ambas cosas: construir un sistema que fuera administrado centralizadamente y que fuese barato, usando modernos microordenadores como base.
La idea era crear un sistema de tiempo compartido para estaciones de trabajo, pero de una manera nueva.
Diferentes ordenadores podrían manejar diferentes tareas, pequeñas y baratas máquinas en oficinas que sevirían como terminales proporcionando acceso a recursos centralizados compartidos como servidores de computación o de almacenamiento. 
Para las máquinas centrales, la moda imperante de multiprocesadores de memoria compartida parecía un candidato obvio.
La filosofía era parecida a la del Cambridge Distributed System [NeHe82]
El objetivo inicial era crear un UNIX a base de sistemas pequeños, no un system a a base de pequeños UNIXes.          
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los problemas con UNIX eran demasiado profundos para arreglarlos, pero algunas de sus ideas podían mantenerse.
La mejor fué su uso de un sistema de ficheros para coordinar el nombre y el acceso a los recursos, incluso si estos, como los dispositivos, no habían sido tradados tradicionalmente como ficheros.
Para Plan 9, adoptamos esta idea diseñando un protocolo a nivel de red llamado 9P, para permitir el acceso a sistemas remotos. Sobre él, construimos un sistema de nombres que permitiría a la gente y a sus máquinas construir vistas personalizadas de los recursos de la red. 
Aquí fué donde Plan 9 empezó a parecer diferente: un usuario de Plan 9 construye un entorno de computación personalizado y lo recrea donde lo desee, en lugar de realizar todo su trabajo en una máquina privada.
Pronto quedó claro que este modelo era mucho más rico que el que habíamos previsto, y la idea de un espacio de nombres por proceso y recursos como sistemas de ficheros se extendieron a todo el sistema &mdash;to procesos, gráficos, incluso la red misma.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">l
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">En 1989 el sistema era suficientemente sólido, tanto que  para que algunos de nosotros se convirtió en el entorno de computación exclusivo. 
Esto significó poner en marcha algunos de los servicios y aplicaciones que habíamos usado en UNIX. Usamos esta oportunidad para revisitar algunas cuestiones, no solamente las propias del nucleo, que creíamos que UNIX no resolvía bien. 
Plan 9 tiene nuevos compiladores, lenguajes, librerías, sistemas de ventanas, y muchas nuevas aplicaciones. Muchas de las viejas herramientas fueron abandonadas, mientras que las que se mantuvieron fueron refinadas o reescritas.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">&iquest;Por qué abarcar tanto?      
La diferencia entre sistema operativo, librería y aplicación es importante para el investigador, pero no lo es para el usuario. Lo que importa es la funcionalidad limpia.
Construyendo un sistema completamente nuevo, podíamos resolver problemas donde creíamos que debían ser resueltos.
Por ejemplo, no hay un driver tty en el nucleo, ese es un trabajo del sistema de ventanas.
En el mundo moderno, la computación multi-sistema y multi-arquitectura es esencial, pero los compiladores y herramientas usuales asumen que el programa se construye para ejecutarse localmente; necesitábamos replantear estas cuestiones.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Más importante aun, la prueba de un sistema es el entorno de computación que proporciona. Producir una forma más eficiente de ejecutar el viejo UNIX es tiempo perdido, estábamos más interesados en si las nuevas ideas sugeridas por la arquitectura subyacente fomentaban una forma de trabajar más efectiva.
Así, aunque Plan 9 proporciona un entorno de emulación para ejecutar comandos POSIX, sólo es un módulo "concreto???" del sistema.
La gran mayoría del software del sistema está desarrollado en el modo &lsquo;nativo&rsquo; del entorno Plan 9.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Tener un sistema completamente nuevo tiene sus beneficios
Primero, nuestro laboratorio tiene una amplia historia de creación experimental de periféricos. Para facilitar la escritura de drivers, queríamos un sistema que estuviese disponible en código fuente (algo que ya no garantizaba UNIX, aún en el laboratorio en el que había nacido). También queríamos redistribuir nuestro trabajo, lo que significaba que el software debía ser producido localmente. Por ejemplo, podríamos haber usado algunos compiladores de marca para nuestro sistema, pero incluso superando los problemas de la compilación cruzada, hubiésemos tenido dificultades distribuyendo el resultado.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Este documento sirve como visión general del sistema. Habla de la arquitectura desde las piezas más pequeñas hasta el entorno que ve el usuario. También sirve como introducción al resto del Manual del Programador del Plan 9, que le acompaña, donde se pueden encontrar más detalles sobre los temas tratados aquí.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Diseño
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La vista del sistema está construida sobre tres principio. Primero, los recursos son nombrados y accedidos como ficheros en un sistema de ficheros jerárquico. Segundo, hay un protocolo estandar, llamado 9P, para acceder a esos recursos. Tercero, las distintas jerarquias proporcionadas por servicios diferentes se unen en un solo espacio de nombres jerárquico privado. Las unusuales propiedades de Plan 9 son consecuencia de la aplicación consistente y enérgica de estos principios.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una instalación Plan 9 grande tiene un número de ordenadores conectados en red, cada uno proporcionando un tipo particular de servicio. Servidores multiprocesador compartidos proporcionan ciclos de computación, otras máquinas ofrecen espacio de almacenamiento. Estas máquinas están localizadas en una sala acondicionada y conectadas a redes de alto rendimiento.
Redes de banda estrecha como Ethernet o ISDN conectan estos servidores a las estaciones de trabajo de la oficina y de casa llamadas terminales en la terminología de Plan 9.
La figura 1 muestra esta disposición.
</span><span style="font-size: 10pt"></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El estilo moderno de computación ofrece a cada usuario una estación de trabajo dedicada o PC.
El enfoque de Plan 9 es diferente.
Las distintas máquinas con pantalla, teclado y raton proporcionan acceso a los recursos de la red,
de manera que son funcionalmente equivalentes, igual que las terminales conectadas a los viejos sistemas
de tiempo compartido.
Cuando alguien usa el sistema, sin embargo, la terminal es temporalmente personalizada para ese usuario.
En lugar de personalizar el hardware, Plan 9 ofrece la habilidad de personalizar la visión del sistema que proporciona 
el software.
Esta personalización se consigue dando nombres locales, personales a los recursos visibles de la red.
Plan 9 proporciona el mecanismo para ensamblar una visión personal del espacio público con nombres locales
para los recursos globalmente accesibles.
Puesto que los recursos más importantes de la red son ficheros, el modelo de esta vista es orientado a ficheros.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El espacio de nombres local del cliente proporciona una forma de personalizar la vista de la red del usuario.
Todos los servicios disponibles en la red exportan jerarquías de ficheros.
Los importantes para el usuario son puestos juntos en un espacio de nombres personal, los que no tienen un interés inmediato son ignorados.
Este es un estilo distinto de uso de la idea de un &lsquo;espacio de nombres uniforme global&rsquo;.
En Plan 9, hay nombres conocidos para servicios y nombres uniformes para ficheros exportados por esos servicios, pero la
vista es enteramente local. Como analogía, considérese la diferencia entre la frase &lsquo;mi casa&rsquo; y el domicilio real del hablante. Cualquiera puede usarlo, pero lo primero es más facil de decir y tiene perfecto sentido en la conversación. También cambia de significado dependiendo de quién lo diga, pero incluso eso no produce ninguna confusión.
De modo similar, en Plan 9 el nombre
</span><span style="font-size: 10pt"><tt>/dev/cons</tt></span><span style="font-size: 10pt">
siempre se refiere a la terminal del usuario y 
</span><span style="font-size: 10pt"><tt>/bin/date</tt></span><span style="font-size: 10pt">
la versión correcta del comando data a ejecutar, pero qué ficheros representan estos nombres dependerá de circunstancias
como la arquitectura de la máquina.
</span><span style="font-size: 10pt"><tt>date</tt></span><span style="font-size: 10pt">.
Plan 9 tiene espacios de nombres locales que obedecen a convenciones establecidad globalmente; y que son las que 
garantizan el comportamiento correcto en presencia de nombres locales.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El protocolo 9P es estructurado como un conjunto de transacciones que envia una solicitud desde un cliente a un servidor
(local o remoto) y que devuelve un resultado. 9P controla sistemas de ficheros, no solamente ficheros: incluye procedimientos para resolver nombres de fichero y recorrer la jerarquía de nombres proporcionada por el servidor.
Por otra parte, el espacio de nombres del cliente es mantenido únicamente por el sistema del cliente, no por o en el servidor, a diferencia de sistemas como Sprite [OCDNW88].
También, el acceso a ficheros es a nivel de bytes, no de bloques, lo que distingue a 9P de protocolos como NFS o RFS.
Un documento de Welch compara estructuras de sistemas de ficheros de red de Sprite, NFS y Plan 9 [Welc94].
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Este enfoque fué diseñado con los ficheros tradicionales en mente, pero puede ser extendido a cualquier tipo de recursos.
Los servicios de Plan 9 que exportan jerarquías de ficheros incluyen dispositivos E/S, servicios de backup, el sistema de ventanas, interfaces de red, y muchos otros. Un ejemplo es el sistema de ficheros de procesos, 
</span><span style="font-size: 10pt"><tt>/proc</tt></span><span style="font-size: 10pt">,
que proporciona una forma de examinar y controlar procesos activos.
Sistemas precursores tuvieron ideas similares [Kill84], pero Plan 9 lleva la metáfora de fichero mucho más alla [PPTTW93].
El modelo de sistema de ficheros se entiende bien, tanto por los programadores como por los usuarios, así que los servicios que presentan interfaces tipo fichero son fáciles de crear, de entender y de usar.
Los ficheros vienen ya, por acuerdo general, con reglas para la protección, el nombre y el acceso local y remoto, así que los servicios construidos en base a ellos están listos para un sistema distribuido.
(Esto es diferente de los modelos &lsquo;orientados a objetos&rsquo;, donde estas cuestiones deben plantearse desde cero para cada clase u objeto)
Estas ideas en acción se ilustran con ejemplos en la siguiente sección.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>La vista a nivel de comando
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 está pensado para ser usado desde una máquina con una pantalla corriendo un sistema de ventanas.
No tiene el concepto de &lsquo;teletipo&rsquo; en el sentido UNIX. El manejo de teclado del sistema es rudimentario, pero una vez que el sistema de ventanas, 8 1/2 [Pike91] está corriendo, el texto puede ser editado con operaciones de cortar y pegar, no solamente en la linea de entrada actual. Las capacidades de edición de texto de 8 1/2 son suficientemente potentes como para desplazar capacidades especiales como la historia de la shell, el paginado y el scroll, y los editores de correo.
Las ventanas de 8 1/2 no soportan el direccionamiento por cursor, y excepto por un emulador de terminal para simplificar la conexión a los sistemas tradicionales, no hay direccionamiento por cursor en Plan 9.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cada ventana se crea en un espacio de nombres separado.
Los ajustes hechos al espacio de nombres en una ventana no afectan a otras ventanas o programas, haciendo seguro experimentar con modificaciones locales, por ejemplo, para sustituir ficheros desde el sistema de ficheros de volcado cuando se hace debugging.
Una vez que se termina, la ventana puede cerrarse, y cualquier rastro de la operación desaparecerá. Similares argumentos se aplican al espacio privado que tiene cada ventana para variables de entorno, notas (análogas a señales en UNIX), etc.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cada ventana se crea ejecutando una aplicación, como una shell, con la entrada y la salida estandar conectadas al texto editable de la ventana. Cada ventana tiene un bitmap privado y multiplexa el acceso al teclado, el ratón, y cualquier otro recurso gráfico a través de ficheros como 
</span><span style="font-size: 10pt"><tt>/dev/mouse</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>/dev/bitblt</tt></span><span style="font-size: 10pt">,
y  
</span><span style="font-size: 10pt"><tt>/dev/cons</tt></span><span style="font-size: 10pt">
(analogos a 
</span><span style="font-size: 10pt"><tt>/dev/tty</tt></span><span style="font-size: 10pt">
de UNIX).
Estos ficheros son proporcionados por 8 1/2, que está implementado como un servidor de ficheros.
A diferencia de X windows, donde una nueva aplicación típicamente crea una nueva ventana para correr en ella, en 8 1/2 las aplicaciones gráficas usualmente corren en la ventana desde la que arrancan. Es posible por eficiencia para una aplicación crear una nueva ventana, pero ese no es el estilo del sistema.
De nuevo en contraste con X, en donde una aplicación remota hace una llamada de red al servidor X para empezar a correr, una aplicación remota 8 1/2 ve los ficheros
</span><span style="font-size: 10pt"><tt>mouse</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>bitblt</tt></span><span style="font-size: 10pt">,
y
</span><span style="font-size: 10pt"><tt>cons</tt></span><span style="font-size: 10pt">
para la ventana como de costumbre en 
</span><span style="font-size: 10pt"><tt>/dev</tt></span><span style="font-size: 10pt">;
no sabe si los ficheros son locales. Solo lee y escribe en ellos para controlar la ventana; la conexión de red ya está ahí y además multiplexada.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El estilo de uso deseado es correr aplicaciones interactivas como el sistema de ventanas y el editor de texto en el terminal y ejecutar aplicaciones de alto consumo de proceso o de espacio de almacenamiento en servidores remotos.
Diferentes ventanas pueden estar ejecutando programas en diferentes máquinas sobre diferentes redes, pero haciendo el espacio de nombres equivalente en todas las ventanas, esto es transparente, los mismos comandos y recursos están disponibles, con los mismos nombres, dondequiera que se realice la computación.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El set de comandos de Plan 9 es similar al de UNIX.
Los comandos se dividen en varias clases. Algunos son programas nuevos para tareas viejas: programas como
</span><span style="font-size: 10pt"><tt>ls</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>cat</tt></span><span style="font-size: 10pt">,
y
</span><span style="font-size: 10pt"><tt>who</tt></span><span style="font-size: 10pt">
tienen nombre y funciones familiares, pero son implementaciones nuevas, más simples
</span><span style="font-size: 10pt"><tt>Who</tt></span><span style="font-size: 10pt">,
por ejemplo, es un script de shell, mientras 
</span><span style="font-size: 10pt"><tt>ps</tt></span><span style="font-size: 10pt">
consiste en 95 lineas de código en C.
Algunos comandos son esencialmente los mismos que sus antecesores UNIX:
</span><span style="font-size: 10pt"><tt>awk</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>troff</tt></span><span style="font-size: 10pt">,
y otros, han sido convertidos a ANSI C y extendidos para manejar Unicode, pero todavía siguen siendo los mismos
Algunos son programas totalmente nuevos para viejos problemas: el shell
</span><span style="font-size: 10pt"><tt>rc</tt></span><span style="font-size: 10pt">,
editor de textos
</span><span style="font-size: 10pt"><tt>sam</tt></span><span style="font-size: 10pt">,
debugger
</span><span style="font-size: 10pt"><tt>acid</tt></span><span style="font-size: 10pt">,
y otros, desplazan a herramientas UNIX bien conocidas con tareas similares.
Finalmente, aproximadamente la mitad de los comandos son nuevos.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La compatibilidad no era un requerimiento del sistema. Donde la versión anterior parecía suficientemente buena, se mantenía. Cuando no se reemplazaba.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>El servidor de ficheros
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Un servidor de ficheros central almacena los ficheros permanentes y los presenta a la red como una jerarquía exportada usando 9P. El servidor es un sistema independiente, accesible solo a través de la red, diseñado para hacer un bien una sola cosa.
No ejecuta procesos de usuario, solo un conjunto fijo de rutinas compiladas en la imagen de arranque.
En lugar de un conjunto de discos o sistemas de ficheros separados, la jerarquía principal exportada por el servidor es un solo árbol, que representa ficheros en varios discos. Esta jerarquía es compartida por muchos usuarios a los largo de un area amplia en una variedad de redes. Otros árboles de ficheros exportados por el servidor incluyen sistemas de propósito especial, como almacenamiento temporal, como explicaremos más adelante y servicio de backup.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El servidor de ficheros tiene tres niveles de almacenamiento. El servidor central de nuestra instalación tiene sobre 100 megabytes de buffers de memoria, 27 gigabytes de discos y 350 gigabytes de almacenamiento en masa, en un jukebox de write-once-read-many (WORM).
El disco es un caché para el WORM y la memoria es un caché para el disco; cada uno es más rápido, y ve un orden de magnitud más de tráfico que el nivel que cachea.
Los datos direccionables en el sistema de ficheros pueden ser superiores al tamaño de los discos magnéticos, puesto que estos solo son un caché; nuestro servidor principal tiene sobre 40 gigabytes de almacenamiento activo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La característica más inusual del sistema de ficheros viene del uso del dispositivo WORM para el almacenamiento definitivo.
Cada mañana, a las 5 en punto, un 
</span><span style="font-size: 10pt"><i>dump</i></span><span style="font-size: 10pt">
del sistema de ficheros ocurre automáticamente.
El sistema es congelado y todos los bloques modificados desde el último volcado son puestos a la cola para ser escritos en el WORM. Una vez que los bloques están en la cola, el servicio se restablece, y la raiz del sistema de ficheros volcado aparece en una jerarquía de todos los volcados que se han realizado hasta el momento, nombrados por su fecha.
Por ejemplo, el directorio
</span><span style="font-size: 10pt"><tt>/n/dump/1995/0315</tt></span><span style="font-size: 10pt">
es la raiz del directorio de una imagen del sistema de ficheros tal como aparecía en la mañana del 15 de Marzo de 1995.
Se tarda pocos minutos en poner en cola todos los bloques, pero el proceso de copia de los bloques al WORM, que corre en background, puede tardar horas.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Hay dos maneras de usar el sistema de ficheros de volcado.
La primera es por los usuarios, que pueden hojear el sistema de ficheros volcado directamente, o enganchar piezas del mismo en su espacio de nombres.
Por ejemplo, para tracear un error, lo más directo es compilar lo que se tenía hace tres meses, o linkar un programa con la librería de ayer.
Con instantáneas diarias de todos los ficheros, es fácil encontrar cuándo un cambio determinado fué hecho, o qué cambios se hicieron después de una fecha. La gente se siente libre de hacer grandes cambios especulativos en los ficheros, seguros de que pueden volver atrás con un simple comando de copia.
No hay un sistema de backup como tal; en su lugar, puesto que los volcados estan en el espacio de nombres, los problemas de backup pueden resolverse con herramientas estandar como 
</span><span style="font-size: 10pt"><tt>cp</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>ls</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>grep</tt></span><span style="font-size: 10pt">,
y   
</span><span style="font-size: 10pt"><tt>diff</tt></span><span style="font-size: 10pt">.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El otro (muy raro) uso es hacer una copia de seguridad del sistema.
En caso de desastre, el sistema de ficheros activo puede ser inicializado desde un volcado, borrando el caché del disco y poniendo la raiz del sistema activo como una copia de la raíz volcada.
Aunque fácil de hacer, no debe tomarse a la ligera: además de perder cualquier cambio realizado en la fecha del volcado, este método de recuperación puede hacer el sistema muy lento.
El caché debe ser recargado desde el WORM, que es mucho más lento que los discos magnéticos.
El sistema de ficheros tardará un par de días en recargar el conjunto de trabajo y recuperar su rendimiento máximo
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los permisos de acceso de los ficheros en el volcado son los mismos que eran en el momento en que se hizo el volcado.
Utilidades normales tienen permisos normales en el volcado sin ningún cuidado especial.
El sistema de ficheros de volcado es, sin embargo, de solo lectura, lo que significa que los ficheros del volcado no pueden ser reescritos, sean cuales sean sus bits de permisos; de hecho, puesto que los directorios son parte de una estructura de solo lectura, incluso los permisos no se les pueden cambiar.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una vez que un fichero es escrito en el WORM, no puede ser borrado, así que nuestros usuarios nunca verán mensajes del tipo  &lsquo;&lsquo;por favor, borre ficheros&rsquo;&rsquo; y no existe el comando 
</span><span style="font-size: 10pt"><tt>df.</tt></span><span style="font-size: 10pt">
Vemos el jukebox WORM como un recurso ilimitado. La única cuestión es cuánto tiempo tardaremos en llenarlo. Nuestro WORM ha servido a una comunidad de unos 50 usuarios durante cinco años y ha absorbido backups diariosr, consumiendo un total del 65% del espacio del jukebox.
En todo ese tiempo, el fabricante ha mejorado la tecnología, doblando la capacidad de los discos individuales. Si nos hubiésemos actualizado, tendríamos más espacio libre que en el jukebox vacio original. La tecnología ha creado espacio más rápido de lo que nosotros lo hemos podido utilizar. 
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Servidores de ficheros inusuales
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 se caracteriza por una variedad de servidores que ofrecen un interfaz de tipo fichero para servicios inusuales. Muchos de estos estan implementados por procesos de nivel de usuario, aunque la distinción no es importante para sus clientes; que un servicio sea proporcionado por el nucleo, por un proceso de usuario, o por un servidor remoto es irrelevante para la forma en que es usado. Hay docenas de estos servidores; in esta sección presentamos tres representativos.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Quizá el servidor de ficheros más extraordinario en Plan 9 es 8 1/2, el sistema de ventanas.
Se comenta en profundidad en otro documento [Pike91], pero merece una breve explicación aqui.
8 1/2 proporciona dos interfaces: al usuario sentado en la terminal, le ofrece un estilo tradicional de interacción con múltiples ventanas, cada una corriendo una aplicación, todo controlado por el teclado y el ratón.
A los programas cliente, la vista que ofrece es también bastante tradicional: los programas corriendo en una ventana ven un gconjunto de ficheros en 
</span><span style="font-size: 10pt"><tt>/dev</tt></span><span style="font-size: 10pt">
con nombres como 
</span><span style="font-size: 10pt"><tt>mouse</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>screen</tt></span><span style="font-size: 10pt">,
y 
</span><span style="font-size: 10pt"><tt>cons</tt></span><span style="font-size: 10pt">.
Los programas que quieren mostrar texto en su ventana escriben en 
</span><span style="font-size: 10pt"><tt>/dev/cons</tt></span><span style="font-size: 10pt">;
para leer el ratón leen
</span><span style="font-size: 10pt"><tt>/dev/mouse</tt></span><span style="font-size: 10pt">.
En el estilo Plan 9, los gráficos bitmap son implementados proporcionando un fichero
</span><span style="font-size: 10pt"><tt>/dev/bitblt</tt></span><span style="font-size: 10pt">
en el que los clientes escriben mensajes codificados para ejecutar operaciones gráficas, como 
</span><span style="font-size: 10pt"><tt>bitblt</tt></span><span style="font-size: 10pt">
(RasterOp).
Lo que es inusual es cómo se hace esto: 8 1/2 es un servidor de ficheros, sirviendo ficheros en 
</span><span style="font-size: 10pt"><tt>/dev</tt></span><span style="font-size: 10pt">
a los clientes que corren en cada ventana.
Aunque cada ventana parece igual para su cliente, cada una tiene un conjunto de ficheros diferente en 
</span><span style="font-size: 10pt"><tt>/dev</tt></span><span style="font-size: 10pt">.
8 1/2 multiplexa el acceso de sus clientes a los recursos de la terminal sirviendo múltiples conjuntos de ficheros. A cada cliente le da un espacio de nombres con un conjunto de ficheros
</span><span style="font-size: 10pt"><i>distinto</i></span><span style="font-size: 10pt">
que se comporta igual que en las demás ventanas.
Este sistema tiene muchas ventajas. Una es que 8 1/2 sirve los mismos ficheros que necesita para su propia implementación  &mdash; multiplexa su propio interfaz &mdash; de modo que puede correr recursivamente como cliente de sí mismo.
También, considérese la implementación de
</span><span style="font-size: 10pt"><tt>/dev/tty</tt></span><span style="font-size: 10pt">
en UNIX, que requiere un código especial en el nucleo para redireccionar llamadas
</span><span style="font-size: 10pt"><tt>open</tt></span><span style="font-size: 10pt">
al dispositivo apropiado.
En lugar de eso, en 8 1/2, el servicio equivalente aparece automáticamente: 8 1/2 sirve 
</span><span style="font-size: 10pt"><tt>/dev/cons</tt></span><span style="font-size: 10pt">
como una de sus funciones básicas, no hay que hacer nada extra.
Cuando un program quiere leer del teclado, abre
</span><span style="font-size: 10pt"><tt>/dev/cons</tt></span><span style="font-size: 10pt">,
pero es un fichero privado, no uno compartido con propiedades especiales.
De nuevo, los espacios de nombres locales hacen esto posible; las convenciones sobre la consistencia de los ficheros lo hacen natural.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.00in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">8 1/2 tiene una característica única que su diseño hace posible.
Como está implementado como un servidor de ficheros, tiene la capacidad de posponer la respuesta a las solicitudes recibidas en una ventana determinada. Este comportamiento es conmutado por una tecla reservada. Pulsandola una vez, se suspende la lectura desde la ventana, pulsándola otra vez, se retoma la lectura normal, que absorve cualquier texto que haya sido preparado, linea a linea.
Esto permite al usuario editar una entrada de texto de varias lineas en la pantalla antes de que la aplicación la reciba, obviando la necesidad de invocar un editor separado para preparar texto como mensajes de correo.
Una propiedad relacionada es que las lecturas son contestadas directamente de la estructura de datos que define el texto en pantalla: el texto puede ser editado hasta que el salto de linea final lo hace legible para el cliente. Incluso entonces, hasta que la linea es leida, el texto que el cliente leerá puede ser cambiado. Por ejemplo, después de teclear
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">No hay comando  
</span><span style="font-size: 10pt"><tt>ftp</tt></span><span style="font-size: 10pt">
en Plan 9. En su lugar, un servidor de ficheros de nivel usuario llamado
</span><span style="font-size: 10pt"><tt>ftpfs</tt></span><span style="font-size: 10pt">
llama al sitio FTP, entra como el usuario, y usa el protocolo FTP para examinar los ficheros en el directorio remoto.
Para el usuario local, ofrece una jerarquía de ficheros enganchada a 
</span><span style="font-size: 10pt"><tt>/n/ftp</tt></span><span style="font-size: 10pt">
en el espacio de nombres local, haciendo un espejo de los contenidos del sitio FTP. 
En otras palabras, traduce el protocolo FTP a 9P, para ofrecer acceso Plan 9 a sitios FTP.
La implementación es delicada:
</span><span style="font-size: 10pt"><tt>ftpfs</tt></span><span style="font-size: 10pt">
debe hacer un cacheo sofisticado por razones de eficiencia, y usar heurística para decodificar la información del directorio remoto. Pero el resultado merece la pena:
todas las herramientas de manejo de ficheros locales como
</span><span style="font-size: 10pt"><tt>cp</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>grep</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>diff</tt></span><span style="font-size: 10pt">,
y, por supuesto
</span><span style="font-size: 10pt"><tt>ls</tt></span><span style="font-size: 10pt">
están disponibles para ficheros servidos por FTP exactamente igual que si fuesen ficheros locales.
Otros sistemas, como Jade y Prospero, han explotado la misma oportunidad [Rao81, Neu92], pero debido a los espacios de nombres locales y a la sencillez de implementación de 9P, este enfoque cae de forma más natural en Plan 9 que en otros entornos.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Un servidor,
</span><span style="font-size: 10pt"><tt>exportfs</tt></span><span style="font-size: 10pt">,
es un proceso de usuario que toma una porción de su propio espacio de nombres y lo hace disponible para otros procesos traduciendo solicitudes 9P a llamadas al sistema del nucleo de Plan 9.
La jerarquía de ficheros que exporta puede contener ficheros de múltiples servidores.
</span><span style="font-size: 10pt"><tt>Exportfs</tt></span><span style="font-size: 10pt">
es usualmente ejecutado como servidor remoto, arrancado por un programa local, que será 
</span><span style="font-size: 10pt"><tt>import</tt></span><span style="font-size: 10pt">
o
</span><span style="font-size: 10pt"><tt>cpu</tt></span><span style="font-size: 10pt">.
</span><span style="font-size: 10pt"><tt>Import</tt></span><span style="font-size: 10pt">
hace una llamada de red a la máquina remota, inicia
</span><span style="font-size: 10pt"><tt>exportfs</tt></span><span style="font-size: 10pt">
allí, y enlaza su conexión 9P al espacio de nombres local. Por ejemplo,
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Configurabilidad y administración
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La interconexión uniforme de componentes en Plan 9 hace posible configurar una instalación de muchas formas distintas.
Un simple PC portatil puede funcionar como sistema Plan 9 autónomo; en el otro extremo, nuestra configuración tiene servidores CPU y servidores de ficheros y cantidad de terminales desde pequeños PC hasta estaciones de trabajo.
Es este tipo de red amplia la que representa mejor cómo opera Plan 9.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El software de sistema es portable, y el mismo sistema operativo corre en todo el hardware. Excepto por el rendimiento, la apariencia del mismo en, digamos una estanción de trabajo SGI es el mismo que en cualquier portatil.
Puesto que la computación y el servicio de ficheros estan descentralizados, y los terminales no tienen almacenamiento permanente, todos los terminales son funcionalmente idénticos.
De esta manera, Plan 9 tiene una de las mejores propiedades de los viejos sistemas de tiempo compartido, en los que un usuario se sentaba frente a una máquina y veía el siempre mismo sistema. En la comunidad moderna de estaciones de trabajo, las máquinas tienden a ser poseidas por gente que las personaliza agregando información privada en su disco local.
Rechazamos este estilo de uso, aunque el sistema mismo puede ser usado así. En nuestro grupo, tenemos un laboratorio con muchas máquinas de acceso público &mdash; una sala de terminales &mdash; y un usuario puede sentarse en cualquiera y trabajar.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los servidores de ficheros centrales no solamente centralizan los ficheros, sino también la administración y el mantenimiento. De hecho, un servidor es el central, y mantiene todos los sistemas de ficheros; otros proporcionan almacenamiento extra, o estan disponibles para debugging u otros usos específicos, pero el software del sistema reside en una máquina. Esto significa que cada programa tiene una sola copia del código binario para cada arquitectura, de modo que es trivial instalar actualizaciones y resolver errores. También hay una sola base de datos de usuarios; no se necesita sincronizar distintos ficheros 
</span><span style="font-size: 10pt"><tt>/etc/passwd.</tt></span><span style="font-size: 10pt">
Por otra parte, depender de un solo servidor central limita el tamaño de una instalación. 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Otro ejemplo del poder del servicio de ficheros centralizado es la forma en que Plan 9 administra la información de red.
En el servidor central hay un directorio,
</span><span style="font-size: 10pt"><tt>/lib/ndb</tt></span><span style="font-size: 10pt">,
que contiene toda la información necesaria para administrar la red local Ethernet y otras redes.
Todas las máquinas usan la misma base de datos para hablar a la red; no hay necesidad e manejar un sistema de nombres distribuido, o mantener actualizados ficheros paralelos. Para instalar una nueva máquina en la Ethernet local, se elige un nombre, una dirección IP y se agrega todo a un solo fichero en 
</span><span style="font-size: 10pt"><tt>/lib/ndb</tt></span><span style="font-size: 10pt">;
todas las máquinas en la instalación podrán comunicarse con ella inmediatamente.
Para empezar a funcionar, se conecta la máquina a la red, se enciende, y se usa BOOTP y TFTP para cargar el nucleo. Todo lo demás es automático.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Finalmente, el volcado automático del sistema de ficheros libera a todos los usuarios de la necesidad de mantener sus sistemas, mientras proporciona fácil acceso a los backups sin cintas, comandos especiales ni personal de soporte. Es difícil exagerar la mejora en el estilo de vida que proporciona este servicio.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 ejecuta una variedad de hardware sin restringir el modo de configurar la instalación.
En nuestro laboratorio, hemos elegido usar servidores centrales puesto que amortizan los costes y la administración. Una señal de que esto es una buena decisión es que nuestras baratas terminales continúan siendo lugares confortables para trabajar cinco años después, mucho más que estaciones de trabajo que deben proporcionar un entorno de computación completo.
No obstante, hemos actualizado las máquinas centrales, así que la computación disponible incluso desde las antiguas terminales de Plan 9 mejora con el tiempo.
El dinero ahorrado al evitar la actualización regular de terminales se ha gastado en cambio en los más modernos y rápidos servidores multiprocesador. Estimamos que aproximadamente por la mitad del coste de las estaciones de trabajo en red proporcionamos acceso general a máquinas más potentes.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Programación en C
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Las utilidades de Plan 9 están escritas en varios lenguajes.
Algunos son scripts de la shell,
</span><span style="font-size: 10pt"><tt>rc</tt></span><span style="font-size: 10pt">
[Duff90]; otras están escritas en un nuevo lenguaje concurrente parecido a C llamado Alef [Wint95], descrito más adelante.
La gran mayoría, sin embargo, esta escrita en un dialecto de ANSI C [ANSIC].
De estos, muchos son programas totalmente nuevos, pero algunos estaban escritos en pre-ANSI C para nuestro sistema de investigación UNIX [UNIX85]. Estos se han actualizado a ANSI C y corregidos para portabilidad y limpieza.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El dialecto de C de Plan 9 tiene algunas extensiones menores, descritas en [Pike95], y algunas grandes restricciones.
La restricción más importante es que el compilador exige que todas las funciones tengan prototipos ANSI y todas las llamadas a funciones deben aparecer en el ámbito de una declaración prototipada de la función.
Como regla de estilo, la declaración prototipada se coloca en el fichero de cabecera incluido por todos los ficheros que llaman a la función. Cada librería de sistema tiene un fichero de cabecera asociado, que declara todas las funciones de la librería. Por ejemplo, la librería estandar de Plan 9 se llama 
</span><span style="font-size: 10pt"><tt>libc</tt></span><span style="font-size: 10pt">,
así que todos los ficheros fuentes en C incluyen
</span><span style="font-size: 10pt"><tt>&lt;libc.h&gt;</tt></span><span style="font-size: 10pt">.
Estas reglas garantízan que todas las funciones sean llamadas con argumentos que tengan los tipos experados &mdash; algo que no ocurría en los programas pre-ANSI C &mdash;
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Otra restricción es que los compiladores de C aceptan solo un subconjunto de las directivas de preprocesador requeridas por ANSI. La omisión principal es
</span><span style="font-size: 10pt"><tt>#if</tt></span><span style="font-size: 10pt">,
porque creemos que nunca es necesaria y que a menudo se abusa de ella.
Además, su efecto se consigue mejor por otros medios. Por ejemplo, un
</span><span style="font-size: 10pt"><tt>#if</tt></span><span style="font-size: 10pt">
usado para conmutar una característica en tiempo de compilación puede ser escrito como una sentencia 
</span><span style="font-size: 10pt"><tt>if</tt></span><span style="font-size: 10pt">
normal, apoyándose en la carácterística de eliminación de código muerto, que proporcina un tiempo de compilación constante y lo descarta del código objeto.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La compilación condicional, incluso con 
</span><span style="font-size: 10pt"><tt>#ifdef</tt></span><span style="font-size: 10pt">,
es escasamente usada en Plan 9.
Los únicos
</span><span style="font-size: 10pt"><tt>#ifdefs</tt></span><span style="font-size: 10pt">
dependientes de la arquitectura en el sistema están en rutinas de bajo nivel, en la librería gráfica. En su lugar, evitamos estas dependencias o, cuando es necesario las aislamos en ficheros o librerías separados.
Además de hacer el código difícil de leer, los 
</span><span style="font-size: 10pt"><tt>#ifdefs</tt></span><span style="font-size: 10pt">
hacen imposible conocer qué fuente es compilada en el binario, o si el fuente protegido por ellos será compilado o funcionará adecuadamente. Hacen más difícil mantener el software.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La librería estandar de Plan 9 coincide bastante con ANSI C y POSIX [POSIX], pero se diverge en lo que respecta a los objetivos o implementación de Plan 9.
Cuando la semántica de una función cambia, le cambiamos también el nombre. Por ejemplo, en lugar del
</span><span style="font-size: 10pt"><tt>creat</tt></span><span style="font-size: 10pt">,
de UNIX, Plan 9 tiene la función 
</span><span style="font-size: 10pt"><tt>create</tt></span><span style="font-size: 10pt">
que toma tres argumentos, los dos originales mas un tercero, que como el segundo de
</span><span style="font-size: 10pt"><tt>open</tt></span><span style="font-size: 10pt">,
define si el descriptor de fichero devuelto será abierto para lectura, escritura o ambas.
Este diseño viene forzado por la forma en la que 9P implementa la creación, pero tambien simplifica el uso normal de 
</span><span style="font-size: 10pt"><tt>create</tt></span><span style="font-size: 10pt">
para inicializar un fichero temporal.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Otra diferencia con ANSI C es que Plan 9 usa un set de caracteres de 16 bits llamado Unicode [ISO10646, Unicode].
Aunque nos detuvimos poco antes de conseguir la total internacionalización, Plan 9 trata la representación de todos los idiomas más importantes de un modo uniforme en todo su software.
Para simplificar el intercambio de texto entre programas, los caracteres se empaquetan en un flujo de bytes por medio de una codificación que nosotros diseñamos, llamada UTF-8, que está siendo ahora aceptada como un estandar [FSSUTF].
Tiene varias propiedades atractivas, incluyendo la independencia de orden de byte, la compatibilidad retroactiva con ASCII, y la facilidad de implementación. 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Hay muchos problemas 
Adaptar software existente a un conjunto de caracteres mayor con una codificación que representa caracteres con un número variable de bytes trae consigo muchos problemas.
ANSI C trata algunos de ellos, pero no consigue resolverlos todos.
No selecciona una codificación para el conjunto de caracteres, y no define las rutinas necesarias de E/S.
Más aún, las funciones que define tienen problemas de diseño. Dado que el estandar dejaba demasiados problemas sin resolver, decidimos crear nuestro propio interfaz. Un documento aparte tiene los detalles [Pike93].
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cierta clase de programas Plan 9 no entran en las convenciones explicadas en esta sección. Son los programas importados de y mantenidos por la comunidad UNIX;
</span><span style="font-size: 10pt"><tt>tex</tt></span><span style="font-size: 10pt">
es un ejemplo representativo.
Para evitar reconvertir estos programas en cada nueva versión, construimos un entorno de porting, llamado ANSI C/POSIX Environment, o APE [Tric95]. APE comprende un conjunto separado de ficheros de cabecera, librerías y comandos, conformes a las estrictas especificaciones ANSI C y POSIX.
Para portar software de red como X Windows, fué necesario agregar algunas extensiones a estas especificaciones, como las funciones de red BSD.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Portabilidad y Compilación
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 es portable a través de una variedad de arquitecturas de procesador.
Dentro de una sola sesión de computación, es normal usar varias arquitecturas, quizá el sistema de ventanas corra en un procesador Intel, conectado a un servidor de CPU basado en MIPS, con ficheros residentes en una SPARC.
Para que esta heterogeneidad sea transparente, debe haber convenciones respecto al intercambio de datos entre programas; para que el mantenimiento sea sencillo debe haber convenciones respecto a la compilación cruzada.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Para evitar problemas de orden de byte, los datos se comunican entre programas como texto, siempre que resulte práctico. A veces, sin embargo, la cantidad de datos es suficientemente alta como para que se necesite un formato binario; estos datos se comunican como un flujo de bytes con una codificación predefinida para valores multi-byte. En el caso raro en que un formato sea tan complejo como para ser definido como una estructura, la estructura nunca se comunica como una unidad, sino que se descompone en campos individuales, se codifica en un flujo de bytes ordenados y se reensambla en el receptor.
Estas convenciones afectan a todos los datos, desde el nucleo o información de estado de programas de aplicación hasta ficheros objeto intermedios generados por el compilador.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los programas, incluido el nucleo, a menudo presentan sus datos a través de un interfaz de sistema de ficheros, un mecanismo de acceso que es inherentemente portable.
Por ejemplo, el reloj del sistema es representado mediante un número decimal en el fichero
</span><span style="font-size: 10pt"><tt>/dev/time</tt></span><span style="font-size: 10pt">;
la función de librería
</span><span style="font-size: 10pt"><tt>time</tt></span><span style="font-size: 10pt">
(no hay una llamada del sistema
</span><span style="font-size: 10pt"><tt>time)</tt></span><span style="font-size: 10pt">
lee el fichero y lo convierte en binario.
De modo parecido, en lugar de codificar el estado de un proceso de una aplicación en una serie de flags y bits en memoria privada, el nucleo presenta una cadena de texto en el fichero llamado
</span><span style="font-size: 10pt"><tt>status</tt></span><span style="font-size: 10pt">
en el sistema de ficheros
</span><span style="font-size: 10pt"><tt>/proc</tt></span><span style="font-size: 10pt">
asociado a cada proceso.
El comando
</span><span style="font-size: 10pt"><tt>ps</tt></span><span style="font-size: 10pt">
en Plan 9 es trivial: muestra los contenidos de los ficheros de estado deseados después de un ligero formateo; más aún, después de hacer
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cada arquitectura soportada tiene su propio compilador y linker.
Los compiladores de C y Alef producen ficheros intermedios que están codificados de manera portable; los contenidos son únicos para la arquitectura destino, pero el formato de los ficheros es independiente del tipo de procesador que compile.
Cuando un compilador para una arquitectura dada es compilado en otro tipo de procesador y luego usado para compilar un programa allí, el código intermedio producido será idéntico al producido en el procesador nativo. Desde la perspectiva del compilador, cada compilación es una compilación cruzada. 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aunque el linker de cada arquitectura acepta solamente ficheros intermedios producidos por compiladores para esa arquitectura, esos ficheros pueden haber sido generados por un compilador ejecutado en otro tipo de procesador. Por ejemplo, es posible correr un compilador MIPS en un 486, y luego usar un linker MIPS en un SPARC para producir un ejecutable MIPS.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Puesto que Plan 9 corre en una variedad de arquitecturas, incluso en una sola instalación, diferenciar compiladores y nombres intermedios simplifica el desarrollo multi-arquitectura en un solo arbol de fuentes. El compilador y el linker para cada arquitectura tienen nombres únicos, no hay un comando 
</span><span style="font-size: 10pt"><tt>cc</tt></span><span style="font-size: 10pt">
Los nombres son derivados de concatenar una letra asociada a la arquitectura destino con el nombre del compilador o del linker. Por ejemplo, el caracter &lsquo;8&rsquo; corresponde a los procesadores 
</span><span style="font-size: 10pt"><i>x</i></span><span style="font-size: 10pt">86
de Intel; el compilador de C se llama
</span><span style="font-size: 10pt"><tt>8c</tt></span><span style="font-size: 10pt">,
el compilador de Alef
</span><span style="font-size: 10pt"><tt>8al</tt></span><span style="font-size: 10pt">,
y el linker 
</span><span style="font-size: 10pt"><tt>8l</tt></span><span style="font-size: 10pt">.
Similarmente, los ficheros intermedios tienen como sufijo
</span><span style="font-size: 10pt"><tt>.8</tt></span><span style="font-size: 10pt">,
y no 
</span><span style="font-size: 10pt"><tt>.o</tt></span><span style="font-size: 10pt">.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El programa de construcción de Plan 9 
</span><span style="font-size: 10pt"><tt>mk</tt></span><span style="font-size: 10pt">,
que es un pariente de 
</span><span style="font-size: 10pt"><tt>make</tt></span><span style="font-size: 10pt">,
lee los nombres de la arquitectura actual y de la destino de variables de entorno llamadas
</span><span style="font-size: 10pt"><tt>$cputype</tt></span><span style="font-size: 10pt">
y  
</span><span style="font-size: 10pt"><tt>$objtype</tt></span><span style="font-size: 10pt">.
Por defecto, el destino es el procesador actual, pero poniendo el valor de
</span><span style="font-size: 10pt"><tt>$objtype</tt></span><span style="font-size: 10pt">
con el nombre de otra arquitectura antes de invocar
</span><span style="font-size: 10pt"><tt>mk</tt></span><span style="font-size: 10pt">
el resultado es una construcción cruzada:
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Programación paralela
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El soporte para programación paralela de Plan 9 tiene dos aspectos.
Primero, el nucleo proporciona un modelo simple de proceso y unas cuantas llamadas al sistema cuidadosamente diseñadas para la sincronización y la compartición.
Segundo, un nuevo lenguaje de programación paralela, llamado Alef que soporta la programación concurrente.
Aunque es posible escribir programas paralelos en C, Alef es el lenguaje más adecuado para ello.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Hay una tendencia en los nuevos sistemas operativos a implementar dos clases de procesos: los procesos normales estilo UNIX y los hilos ligeros.
En lugar de esto, Plan 9 proporciona una sola clase de procesos pero permite un control preciso de la compartición entre procesos de recursos como memoria o descriptores de ficheros.
Una sola clase de procesos es un enfoque más viable en Plan 9, puesto que el nucleo tiene un interfaz eficiente de llamadas al sistema y una creación y planificación de procesos eficiente.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los programas paralelos tienen tres requerimientos básicos:
manejo de recursos compartido entre procesos,
un interfaz con el planificador,
y una sincronización precisa mediante &lsquo;bloqueos giratorios&rsquo;???????.
En Plan 9, los procesos se crean usando la llamada del sistema
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
</span><span style="font-size: 10pt"><tt>Rfork</tt></span><span style="font-size: 10pt">
toma un solo argumento, un vector de bits que especifica cuál de los recursos del proceso padre deben ser compartidos, copiados o creados de nuevo en el proceso hijo.
Los recursos controlados por
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
incluyen el espacio de nombres, el entorno, la tabla de descriptores de ficheros, segmentos de memoria, y notas (equivalentes a señales en UNIX). Uno de los bits controla si
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
creará un proceso nuevo; si el bit está en off, las modificaciones resultantes de los recursos ocurrirán en el proceso que hace la llamada. Por ejemplo, un proceso llama 
</span><span style="font-size: 10pt"><tt>rfork(RFNAMEG)</tt></span><span style="font-size: 10pt">
para desconectar su espacio de nombres del de su padre.
Alef usa un fork de grano fino, en el que todos los recursos, incluyendo memoria, son compartidos entre el padre y el hijo, de forma análoga a como se crean hilos del nucleo en muchos sistemas. 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Algo que demuestra que
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
es el modelo correcto es la variedad de formas en que es utilizado.
Aparte del uso canónico de la rutina de librería 
</span><span style="font-size: 10pt"><tt>fork</tt></span><span style="font-size: 10pt">,
es difícil encontrar dos llamadas a 
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
con el mismo conjunto de bits; los programas lo usan para crear muchas formas distintas de compartición y de asignación de recursos.
Un sistema con solo dos tipos de procesos &mdash; procesos normales e hilos &mdash; no puede manejar esta variedad.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Hay dos formas de compartir memoria.
Primero, un flag a
</span><span style="font-size: 10pt"><tt>rfork</tt></span><span style="font-size: 10pt">
hace que todos los segmentos de memoria del padre sean compartidos con el hijo (excepto la pila, que es 
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">????????
forked copy-on-write regardless).
????????
causes all the memory segments of the parent to be shared with the child
(except the stack, which is
forked copy-on-write regardless).
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Alternativamente, un segmento nuevo de memoria puede enlazarse usando la llamada del sistema
</span><span style="font-size: 10pt"><tt>segattach</tt></span><span style="font-size: 10pt">
; este segmento será siempre compartido entre padre e hijo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La llamada 
</span><span style="font-size: 10pt"><tt>rendezvous</tt></span><span style="font-size: 10pt">
proporciona una forma de sincronizar procesos.
Alef la usa para implementar canales de comunicación, colas de bloqueo, bloqueos de múltiple lector/escritor, y el mecanismo de dormir y despertar. 
</span><span style="font-size: 10pt"><tt>Rendezvous</tt></span><span style="font-size: 10pt">
toma dos argumentos, una etiqueta y un valor.
Cuando un proceso llama a 
</span><span style="font-size: 10pt"><tt>rendezvous</tt></span><span style="font-size: 10pt">
con una etiqueta, se duerme hasta que otro proceso presenta una etiqueta coincidente.
Cuando un par de etiquetas coinciden, los valores se intercambian entre ambos procesos y ambas llamadas
</span><span style="font-size: 10pt"><tt>rendezvous</tt></span><span style="font-size: 10pt">
retornan.
Esta primitiva es suficiente para implementar el conjunto completo de rutinas de sincronización.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Finalmente, se proporcionan bloqueos giratorios por una librería dependiente de cada arquitectura a nivel usuario.
La mayoría de los procesadores proveen instrucciones atómicas de test y set que pueden ser usadas para implementar bloqueos.
Una excepción notable es el MIPS R3000, así que la seria SGI Power de multiprocesadores tienen un hardware de bloqueo especial en el bus.
Los procesos de usuario ganan acceso al bloqueo de hardware mapeando páginas de bloqueos hardware en su espacio de direcciones usando la llamada 
</span><span style="font-size: 10pt"><tt>segattach</tt></span><span style="font-size: 10pt">
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Un proceso de Plan 9 en una llamada del sistema se bloqueará sin tener en cuenta su &lsquo;peso&rsquo;. Esto quiere decir que cuando un programa desea leer desde un dispositivo lento sin bloquear el cálculo completo, debe bifurcar un proceso para que lea por él. La solución es arrancar un proceso satélite que haga la E/S y envíe la respuesta al programa principal a través de memoria compartida o quizas de un pipe.
Esto suena complejo, pero funciona fácil y eficientemente en la práctica; de hecho, la mayoría de aplicaciones interactivas de Plan 9, incluso las relativamente ordinarias escritas en C, como el editor de texto Sam [Pike87], corren como programas multiproceso.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El soporte del nucleo para programación paralela en Plan 9 consiste en unos cuantos cientos de lineas de código portable; unas cuantas primitivas simples permiten que los problemas se manejen limpiamente desde el nivel de usuario.
La creación y manejo de procesos de E/S esclavos puede ser escrita en unas pocas lineas de Alef, proporcionando las bases para un medio consistente de multiplexado de flujos de datos entre procesos arbitrarios.
Más aún, implementar eso en un lenguaje, en lugar de en el nucleo asegura una semántica consistente entre todos los dispositivos y proporciona una primitiva de multiplexado más general.
Compárese esto con la llamada del sistema de UNIX
</span><span style="font-size: 10pt"><tt>select</tt></span><span style="font-size: 10pt">
</span><span style="font-size: 10pt"><tt>select</tt></span><span style="font-size: 10pt">
se aplica solamente a un conjunto restringido de dispositivos, regula un estilo de multiprogramación en el nucleo, no es extesible a través de redes, es difícil de implementar y es difícil de usar.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Otra razón por la que la programación paralela es importante en Plan 9 es que los servidores de fichero multi-hilo de nivel usuario son la forma preferida de implementar servicios.
Ejemplos de estos servicios incluyen el entorno de programación Acme [Pike94], la herramienta de exportación de espacios de nombres 
</span><span style="font-size: 10pt"><tt>exportfs</tt></span><span style="font-size: 10pt">
[PPTTW93],
el demonio de HTTP, y los servidores de nombres de red
</span><span style="font-size: 10pt"><tt>cs</tt></span><span style="font-size: 10pt">
y 
</span><span style="font-size: 10pt"><tt>dns</tt></span><span style="font-size: 10pt">
[PrWi93].
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">????????????? 
Aplicaciones complejas como Acme demuestran que un soporte cuidadoso por parte del sistema operativo puede reducir la dificultad de escribir aplicaciones multi-hilo sin mover las primitivas de hilos y de sincronización al nucleo.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Complex applications such as Acme prove that
careful operating system support can reduce the difficulty of writing
multi-threaded applications without moving threading and
synchronization primitives into the kernel.
????????????
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Implementación de espacios de nombres
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los procesos de usuario construyen espacios de nombres usando tres llamadas del sistema:
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>bind</tt></span><span style="font-size: 10pt">,
y
</span><span style="font-size: 10pt"><tt>unmount</tt></span><span style="font-size: 10pt">.
La llamada
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">
engancha un arbol servido por un servidor de ficheros al espacio de nombres actual. Antes de llamar a 
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">,
el cliente debe (por medios externos) adquirir una conexión con el servidor en forma de un descriptor de fichero que puede ser leido y escrito para transmitir mensajes 9P.
Este descriptor de fichero representa un pipe o una conexión de red.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La llamada
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">
engancha una nueva jerarquía al espacio de nombres existente.
La llamada
</span><span style="font-size: 10pt"><tt>bind</tt></span><span style="font-size: 10pt">
por otra parte, duplica una parte del espacio de nombres en otro punto del mismo espacio.
La llamada
</span><span style="font-size: 10pt"><tt>unmount</tt></span><span style="font-size: 10pt">
permite retirar componentes.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Con el uso de 
</span><span style="font-size: 10pt"><tt>bind</tt></span><span style="font-size: 10pt">
o
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">,
pueden apilarse múltiples directorios en un solo punto del espacio de nombres. En la terminología de Plan 9, esto es una 
</span><span style="font-size: 10pt"><i>union</i></span><span style="font-size: 10pt">
de directorios y se comporta como la concatenación de los directorios que la constituyen.
Un argumento de
</span><span style="font-size: 10pt"><tt>bind</tt></span><span style="font-size: 10pt">
y de 
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">
especifica la posición del nuevo directorio en la unión, permitiendo a los nuevos elementos agregarse al inicio de la unión o bien reemplazar la jerarquía completa.
Cuando se realiza una búsqueda de un fichero en una unión de directorios, cada componente de la unión se busca por turno, y se toma el primero que coincida; del mismo modo, cuando se lee una unión de directorios, los contenidos de cada directorio son leidos por turno.
La unión de directorios es uno de las características de organización más ampliamente usadas de los espacios de nombres de Plan 9.
Por ejemplo, el directorio
</span><span style="font-size: 10pt"><tt>/bin</tt></span><span style="font-size: 10pt">
se crea como unión de
</span><span style="font-size: 10pt"><tt>/$cputype/bin</tt></span><span style="font-size: 10pt">
(binarios de programas),
</span><span style="font-size: 10pt"><tt>/rc/bin</tt></span><span style="font-size: 10pt">
(scripts de la shell),
y quizá más directorios proporcionados por el usuario.
Esta construcción hace innecesaria la variable 
</span><span style="font-size: 10pt"><tt>$PATH</tt></span><span style="font-size: 10pt">
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una cuestión que surge con la unión de directorios es cuál elemento de la unión recibe un fichero recien creado.
Después de varios diseños, decidimos lo siguiente.
Por defecto, los directorios de una unión no aceptan ficheros nuevos, aunque la llamada del sistema
</span><span style="font-size: 10pt"><tt>create</tt></span><span style="font-size: 10pt">
aplicada a un fichero existente tiene éxito normalmente.
Cuando un directorio es agregado a una unión, una bandera en 
</span><span style="font-size: 10pt"><tt>bind</tt></span><span style="font-size: 10pt">
o en 
</span><span style="font-size: 10pt"><tt>mount</tt></span><span style="font-size: 10pt">
habilita el permiso de creación (una propiedad del espacio de nombres) en ese directorio.
Cuando un fichero está siendo creado con un nombre nuevo en la unión, es creado en el primer directorio de la unión con permiso de creación; si esa creación falla, el
</span><span style="font-size: 10pt"><tt>create</tt></span><span style="font-size: 10pt">
falla.
Este esquema permite el uso común de colocar un directorio privado en alguna parte de una unión de directorios públicos, mientoras que permite la creación solamente en el directorio privado.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Por convenio, los sistemas de ficheros de dispositivos del nucleos están enlazados al directorio
</span><span style="font-size: 10pt"><tt>/dev</tt></span><span style="font-size: 10pt">
pero para iniciar el proceso de construcción de espacio de nombres, es necesario tener una notación que permita acceso directo a los dispositivos sin un espacio de nombres existente.
El directorio raíz del árbol servido por un driver de dispositivo puede ser accedido usando la sintaxis
</span><span style="font-size: 10pt"><tt>#</tt></span><span style="font-size: 10pt"></span><span style="font-size: 10pt"><i>c</i></span><span style="font-size: 10pt">,
donde
</span><span style="font-size: 10pt"><i>c</i></span><span style="font-size: 10pt">
es un carácter único (típicamente una letra) que indentifica el 
</span><span style="font-size: 10pt"><i>tipo</i></span><span style="font-size: 10pt">
de dispositivo.
Drivers de dispositivo simples sirven un directorio de un solo nivel que contiene unos pocos ficheros.
Como ejemplo, cada puerto serie se representa por un fichero de datos y otro de control.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Es el uso universal del protocolo 9P el que conecta los componentes de Plan 9 para formar un sistema distribuido.
En lugar de inventar un protocolo único para cada servicio como 
</span><span style="font-size: 10pt"><tt>rlogin</tt></span><span style="font-size: 10pt">,
FTP, TFTP, y X Windows,
Plan 9 implementa servicios en términos de operaciones sobre objetos fichero, y luego utiliza un simple y bien documentado protocolo para intercambiar información entre equipos.
A diferencia de NFS, 9P trata los ficheros como una secuencia de bytes en lugar de como bloques. Tambien, a diferencia de NFS, 9P guarda su estado: los clientes realizan llamadas a procedimientos remotos para establecer punteros a objetos en el servidor de ficheros remoto.
Estos punteros se llaman identificadores de fichero, o
</span><span style="font-size: 10pt"><i>fids</i></span><span style="font-size: 10pt">.
Todas las operaciones sobre ficheros devuelven un fid para identificar el objeto en el sistema de ficheros remoto.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El protocolo 9P define 17 mensajes, proporcionando medios para autenticar usuarios, navigar por los fids de una jerarquía de ficheros, copiar fids, realizar E/S, cambiar atributos de ficheros, y crear y borrar ficheros.
Su especificación completa está en la sección 5 del Manual del Programador [9man].
Veamos el procedimiento para obtener acceso a la jerarquía de nombres proporcionada por un servidor.
Se establece una conexión al servidor mediante un pipe o una conexión de red.
Un mensaje inicial
</span><span style="font-size: 10pt"><tt>session</tt></span><span style="font-size: 10pt">
realiza la autentificación bilateral entre cliente y servidor.
Un mensaje
</span><span style="font-size: 10pt"><tt>attach</tt></span><span style="font-size: 10pt">
conecta entonces un fid sugerido por el cliente a la raíz del arbol de ficheros del servidor
El mensaje
</span><span style="font-size: 10pt"><tt>attach</tt></span><span style="font-size: 10pt">
incluye la identidad del usuario que realiza el enganche; en adelante, todos los fids derivados del fid raíz tendrán los permisos asociados con ese usuario.
Muchos usuarios pueden compartir la conexión, pero cada uno debe realizar un attach para establecer su identidad
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El mensaje
</span><span style="font-size: 10pt"><tt>walk</tt></span><span style="font-size: 10pt">
mueve un fid a través de un nivel de la jerarquía de ficheros.
El mensaje
</span><span style="font-size: 10pt"><tt>clone</tt></span><span style="font-size: 10pt">
toma un fid establecido y produce una copia que apunta al mismo fichero que el original.
Su propósito es permitir el walking a un fichero del directorio sin perder el fid de ese directorio.
El mensaje
</span><span style="font-size: 10pt"><tt>open</tt></span><span style="font-size: 10pt">
bloquea un fid a un fichero específico de la jerarquía, comprobando los permisos de acceso y prepara el fid para E/S.
Los mensajes
</span><span style="font-size: 10pt"><tt>read</tt></span><span style="font-size: 10pt">
y  
</span><span style="font-size: 10pt"><tt>write</tt></span><span style="font-size: 10pt">
permiten E/S en desplazamientos arbitrarios en el fichero; el tamaño máximo transferido es definido por el protocolo.
El mensaje
</span><span style="font-size: 10pt"><tt>clunk</tt></span><span style="font-size: 10pt">
indica que el cliente ya no necesita un fid.
El mensaje
</span><span style="font-size: 10pt"><tt>remove</tt></span><span style="font-size: 10pt">
se comporta como 
</span><span style="font-size: 10pt"><tt>clunk</tt></span><span style="font-size: 10pt">
pero hace que el fichero asociado con ese fid sea borrado, y cualquier recurso asociado con el servidor sea liberado.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">9P tiene dos formas: mensajes RPC enviados a un pipe o a una conexión de red y un interfaz procedural dentro del nucleo.
Dado que los drivers del nucleo se pueden direccionar directamente, no se necesita pasar mensajes para comunicarse con ellos; en lugar de esto, cada transacción 9P es implementada mediante una llamada directa a un procedimiento.
Para cada fid, el nucleo mantiene una representación local en una estructura de datos llamada
</span><span style="font-size: 10pt"><i>channel</i></span><span style="font-size: 10pt">,
de modo que todas las operaciones sobre ficheros realizadas por el nucleo implican un canal conectado a ese fid.
El ejemplo más simple son los descriptores de fichero de un proceso de usuario, que son índices a un array de canales.
Una tabla del nucleo proporciona una lista de puntos de entrada correspondientes, uno a uno, con los mensajes de cada dispositivo.
Una llamada del sistema como 
</span><span style="font-size: 10pt"><tt>read</tt></span><span style="font-size: 10pt">
desde el usuario se traduce en una o más llamadas a procedimientos a través de esa tabla, indexada por el caracter de tipo almacenado en el canal:
</span><span style="font-size: 10pt"><tt>procread</tt></span><span style="font-size: 10pt">,
</span><span style="font-size: 10pt"><tt>eiaread</tt></span><span style="font-size: 10pt">,
etc.
Cada llamada toma al menos un canal como argumento. Un driver especial del nucleo, llamado el driver
</span><span style="font-size: 10pt"><i>mount</i></span><span style="font-size: 10pt">
traduce las llamadas a procedimientos a mensajes, es decir, convierte los procedimientos locales en remotos.
En efecto, este driver especial viene a ser un proxy local para los ficheros servidos por un servidor remoto.
El puntero al canal en la llamada local se traduce al fid asociado en el mensaje transmitido.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El driver mount es el único mecanismo RPC empleado por el sistema.
La semántica de los ficheros proporcionados, en lugar de las operaciones realizadas sobre ellos, crea un servicio particular, como el comando
</span><span style="font-size: 10pt"><tt>cpu</tt></span><span style="font-size: 10pt">
El driver mount demultiplexa los mensajes del protocolo entre clientes que comparten un mismo canal de comunicación con el servidor de ficheros. Para cada mensaje RPC saliente, el driver mount asigna un buffer etiquetado con un pequeño entero único, llamado 
</span><span style="font-size: 10pt"><i>tag</i></span><span style="font-size: 10pt">.
La respuesta al RPC es etiquetada con la misma tab, que es usada por el driver mount para hacer corresponder la repuesta con la solicitud.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La representación en el nucleo del espacio de nombres es llamada
</span><span style="font-size: 10pt"><i>tabla de mount</i></span><span style="font-size: 10pt">,
y almacena una lista de enlaces entre canales.
Cada entrada en la tabla de mount contiene un par de canales: un canal
</span><span style="font-size: 10pt"><i>from</i></span><span style="font-size: 10pt">
y un canal
</span><span style="font-size: 10pt"><i>to</i></span><span style="font-size: 10pt">
Cada vez que un walk tiene éxito moviendo un canal a un nuevo lugar en el espacio de nombres, la tabla mount se consulta para ver si el canal &lsquo;from&rsquo; coincide con el nuevo nombre; si es así, el canal &lsquo;to&rsquo; es clonado y sustituido por el original.
Las uniones de directorios se implementan convirtiendo el canal &lsquo;to&rsquo; en una lista de canales: un walk con éxito a una unión de directorios devuelve un canal &lsquo;to&rsquo; que constituye la cabecera de una lista de canales, cada uno representando a un directorio de la unión.
Si un walk falla al encontrar un fichero en el primer directorio de la unión, se sigue la lista, el siguiente componente es clonado, y se intenta un walk en él.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cada fichero en Plan 9 es identificado unívocamente por un conjunto de enteros: el tipo de canal (usado como índice de la tabla de llamadas), el servidor o número de dispositivo, distinguiendo el servidor de otros del mismo tipo (decidido localmente por el driver), y un 
</span><span style="font-size: 10pt"><i>qid</i></span><span style="font-size: 10pt">
formado por un número de 32 bits llamado
</span><span style="font-size: 10pt"><i>path</i></span><span style="font-size: 10pt">
y
</span><span style="font-size: 10pt"><i>version</i></span><span style="font-size: 10pt">.
El path es un número de fichero único asignado por el driver o por el servidor de ficheros cuando el fichero es creado.
El número de versión es actualizado cada vez que el fichero se modifica; tal como se describe en la siguiente sección, i puede usarse para mantener la coherencia en el caché entre clientes y servidores.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">??????
El tipo y número de dispositivo son análogos a los números de dispositivo mayor y menor de UNIX; el quid es análogo al número-i. (nodo-i, i-node,...) ????????
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">The type and device number are analogous to UNIX major and minor
device numbers; the qid is analogous to the i-number.
???????
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El dispositivo y tipo conectan el canal a un driver, y el qid identifica el fichero dentro del dispositivo.
Si el fichero obtenido en el walk tiene el mismo tipo, dispositivo y qid que una entrada en la tabla mount, entonces son el mismo fichero y se realiza la sustitución correspondiente en la tabla.
Así es como está implementado el espacio de nombres.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Caché de ficheros
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El protocolo 9P no tiene soporte explícito para cachear ficheros en un cliente.
La extensa memoria del servidor central de ficheros actua como un caché compartido para todos sus clientes, lo que reduce la cantidad total de memoria necesaria para todas las máquinas de la red.
No obstante, hay razones de peso para cachear ficheros en el cliente, como una conexión lenta con el servidor.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El campo version del qid se cambia siempre que el fichero se modifica, lo que posibilita en cierta forma el cacheo. Lo más importante es el cacheo en el cliente de los segmentos de texto y de datos de los ficheros ejecutables.
Cuando un proceso ejecuta un programa, el fichero es reabierto y la versión del qid se compara con la del caché; si coinciden, se usa la copia local.
El mismo método puede usarse para crear un servidor de ficheros local con caché.
Este servidor de nivel usuario puede se interpone en la conexión 9P al servidor remoto y monitorea el tráfico, copiando datos al disco local. Cuando ve una lectura de datos conocidos, contesta directamente, mientras que las escrituras las pasa inmediatamente &mdash; el caché es escribible &mdash; para mantener los datos centrales actualizados.
Esto es transparente para los procesos del terminal, y no requiere cambios en 9P; funciona bien en máquinas de casa conectadas por lineas serie.
Un método similar puede aplicarse para construir un caché general de cliente en memoria local no utilizada, pero esto no se ha hecho en Plan 9.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Redes y dispositivos de comunicación
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los interfaces de red son sistemas de ficheros residentes del nucleo, análogos a los dispositivos EIA descritos anteriormente.
Las llamadas de setup y shutdown pueden realizarse escribiendo cadenas de texto en el fichero de control asociado con el dispositivo; la información es enviada y recibida leyendo y escribiendo en un fichero de datos.
La estructura y semántica del los dispositivos es común a todas las redes, así que aparte de cambiar el nombre del fichero, un mismo procedimiento puede llamar usando TCP sobre Ethernet como URP sobre Datakit [Fra80].
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Este ejemplo ilustra la estructura de los dispositivos TCP:
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una llamada se inicia escribiendo un mensaje connect con una dirección de red como argumento; por ejemplo, para abrir una sesión Telnet (puerto 23) en una máquina remota con la dirección IP 135.104.9.52, la cadena es:
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una simple función de librería llamada
</span><span style="font-size: 10pt"><tt>dial</tt></span><span style="font-size: 10pt">
se comunica con 
</span><span style="font-size: 10pt"><tt>cs</tt></span><span style="font-size: 10pt">
para establecer la conexión.
Una aplicación que usa
</span><span style="font-size: 10pt"><tt>dial</tt></span><span style="font-size: 10pt">
no necesita cambios, ni siquiera recompilación, para adaptarse a nuevas redes;  el interfaz con
</span><span style="font-size: 10pt"><tt>cs</tt></span><span style="font-size: 10pt">
oculta los detalles.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La uniforme estructura para las redes en Plan 9 hace que el comando
</span><span style="font-size: 10pt"><tt>import</tt></span><span style="font-size: 10pt">
sea lo único que se necesita para construir una pasarela.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Estructura del nucleo para redes
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La fontanería utilizada en el nucleo de Plan 9 para canales de comunicación se llama
</span><span style="font-size: 10pt"><i>streams</i></span><span style="font-size: 10pt">
[Rit84][Presotto].
???????????
Una stream es un canal bidireccional que conecta un dispositivo (físico o lógico) con un proceso de usuario.
A stream is a bidirectional channel connecting a physical or pseudo-device to a user process.
???????????
El proceso de usuario inserta y retira datos en cada extremo de la stream; un proceso de nucleo, que actua en nombre del dispositivo opera al otro lado.
Una stream comprende una lista lineal de 
</span><span style="font-size: 10pt"><i>módulos en proceso</i></span><span style="font-size: 10pt">.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">????????????
Cada módulo tiene una 
</span><span style="font-size: 10pt"><i>put routine</i></span><span style="font-size: 10pt">.
de upstream (hacia el proceso) y de downstream (hacia el dispositivo)
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Each module has both an upstream (toward the process) and
downstream (toward the device)
</span><span style="font-size: 10pt"><i>put routine</i></span><span style="font-size: 10pt">.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una llamada a la rutina put del módulo en cualquiera de ambos lados inserta datos en la stream.
Cada módulo llama sucesivamente a una para enviar datos desde o hacia la stream.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Calling the put routine of the module on either end of the stream
inserts data into the stream.
Each module calls the succeeding one to send data up or down the stream.
???????????
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Al igual que en las streams de UNIX [Rit84], las de Plan 9 pueden configurarse dinámicamente.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>El protocolo IL
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El protocolo 9P debe ejecutarse sobre un protocolo de transporte fiable, con mensajes delimitados. 9P carece de mecanismos para recuperarse de errores de transmisión y el sistema sume que cada lectura de un canal de comunicación devolverá un solo mensaje 9P; no analiza la corriente de datos para descubrir límites de mensajes. Los pipes y algunos protocolos de red ya tienen estas propiedades, pero los protocolos estandar IP no.
TCP no delimita los mensajes, mientras que UDP [RFC768] no proporciona una distribución en orden fiable.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Nosotros diseñamos un procoloco nuevo, llamado IL (Internet Link), para transmitir mensajes 9P sobre IP.
Es un protocolo basado en conexión, que proporciona transmisiones fiables de mensajes en secuencia entre máquinas.
Puesto que un proceso puede tener pendiente solamente una solicitud 9P, no hay necesidad de control de flujo en IL.
Como TCP, IL tiene timeouts adaptables: escala los tiempos de acknowledge y retransmisión según la velocidad de la red.
Esto le permite un buen rendimiento tanto en Internet como en Ethernet local. También, IL no hace retransmisión a ciegas, para evitar congestionar redes sobrecargadas.
Todos los detalles sobre él están en otro documento [PrWi95].
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">En Plan 9, la implementación de IL es más pequeña y rápida que TCP. IL es nuestro protocolo de transporte principal de Internet.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Visión general de la autenticación
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La autenticación establece la identidad de un usuario que accede a un recurso. El usuario que solicita el recurso se llama
</span><span style="font-size: 10pt"><i>cliente</i></span><span style="font-size: 10pt">
y el usuario que garantiza acceso al recurso se llama
</span><span style="font-size: 10pt"><i>servidor.</i></span><span style="font-size: 10pt">
Esto se hace usualmente bajo los auspicios de un mensaje 9P enganchado.
El usuario puede ser cliente en un intercambio de autenticación y servidor en otro. Los servidores siempre actuan en nombre de un usuario, sea un cliente normal o una entidad administrativa, de modo que la autenticación se define entre usuarios, no entre máquinas.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cada usuario de Plan 9 tiene una clave DES [NBS77] asociada; su identidad es verificada por la habilidad de desencriptar mensajes especiales llamados desafíos. Puesto que el conocimiento de la clave de un usuario da acceso a sus recursos, los protocolos de autenticación de Plan 9 nunca transmiten un mensaje que contenga la clave en texto plano.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La autenticación es bilateral: a cada extremo de un intercambio de autenticación, cada parte debe convencer a la otra de su identidad. Cada máquina empieza el intercambio con una clave DES en memoria. In el caso de servidores de CPU o de ficheros, la clave, nombre de usuario y de dominio para el servidor se leen del almacenamiento permanente, usualmente RAM no volatil.
En el caso de terminales, la clave se deriva de la password tecleada por el usuario en el arranque.
Una máquina especial, conocida como 
</span><span style="font-size: 10pt"><i>servidor</i></span><span style="font-size: 10pt">de
</span><span style="font-size: 10pt"><i>autenticación,</i></span><span style="font-size: 10pt">
mantiene una base de datos de claves de todos los usuarios en su dominio administrativo y participa en los protocolos de autenticación.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El procoloco de autenticación funciona así:
después de intercambiar los desafíos, cada parte contacta con el servidor de autenticación para crear 
</span><span style="font-size: 10pt"><i>tickets</i></span><span style="font-size: 10pt">
de concesión de permisos encriptados con su clave secreta y que contienen una clave de conversación.
Cada parte desencripta su propio ticket y usa la clave de conversación para encriptar el desafío de la otra.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Esta estructura es parecida a la de Kerberos [MBSS87], pero evita su dependencia de los bloques sincronizados.
También, a diferencia de Kerberos, la autenticación de Plan 9 soporta la relación &lsquo;hablar en nombre de&rsquo; [LABW91] que permite a un usuario tener la autoridad de otro; así es como un servidor de CPU realiza procesos en nombre de sus clientes.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La estructura de autenticación de Plan 9 construye servicios seguros, en lugar de depender de cortafuegos.
Mientras que los cortafuegos requieren código especial para cada servicio que penetra el muro, el enfoque de Plan 9 permite que la autenticación se haga en un solo sitio &mdash; para todos los servicios &mdash;
Por ejemplo, el comando
</span><span style="font-size: 10pt"><tt>cpu</tt></span><span style="font-size: 10pt">
funciona con seguridad a través de Internet.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>La autenticación de conexiones externas
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El protocolo de autenticación normal de Plan 9 no es válido para servicios basados en texto como Telnet o FTP.
En estos casos, los usuarios de Plan 9 se autentican con calculadores DES llamados 
</span><span style="font-size: 10pt"><i>autenticadores</i></span><span style="font-size: 10pt">.
El autenticador mantiene una clave para el usuario, distinta de su clave normal de usuario. El usuario entra en el autenticador con un PIN de 4 dígitos. Un PIN correcto habilita al autenticador para un intercambio desafío/respuesta con el servidor.
Dado que dicho intercambio es válido solo una vez y que las claves nunca se envían por la red, este procedimiento no es susceptible a ataques de repetición, pero es compatible con protocolos como Telnet y FTP.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Usuarios especiales
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 no tiene super-usuario.
Cada servidor es responsable de mantener su propia seguridad, normalmente permitiendo acceso solamente por la consola, que está protegida por una password. Por ejemplo, los servidores de ficheros tienen un único usuario administrativo llamado 
</span><span style="font-size: 10pt"><tt>adm</tt></span><span style="font-size: 10pt">,
con privilegios especiales que se aplican solamente a los comandos tecleados en la consola física del servidor.
Estos privilegios conciernen al mantenimiento diario del servidor, como agregar usuarios y configurar discos y redes.
Los privilegios 
</span><span style="font-size: 10pt"><i>no</i></span><span style="font-size: 10pt">
incluyen la capacidad de modificar, examinar o cambiar los permisos de ningún fichero. Si un fichero está protegido para lectura por el usuario, solamente él puede conceder a los demás acceso al mismo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los servidores de CPU tienen un nombre de usuario equivalente que permite el acceso administrativo a los recursos en ese servidor como los ficheros de control o los procesos de usuario. Este permiso es necesario, por ejemplo, para matar un proceso no deseado, pero no se extiende más alla de ese servidor. Por otra parte, por medio de la clave guardada en RAM no volatil, la identidad de un usuario administrador es probada para el servidor de autenticación.
Esto permite al servidor de CPU autenticar a usuarios remotos, tanto para que accedan al servidor mismo como cuando el servidor está actuando como un proxy en nombre de ellos.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Finalmente, un usuario especial llamado
</span><span style="font-size: 10pt"><tt>none</tt></span><span style="font-size: 10pt">
no tiene password y siempre se le permite conectarse; cualquiera puede ser
</span><span style="font-size: 10pt"><tt>none</tt></span><span style="font-size: 10pt">.
</span><span style="font-size: 10pt"><tt>None</tt></span><span style="font-size: 10pt">
tiene permisos restringidos; por ejemplo, no se le permite examinar ficheros de volcado y solo puede leer los ficheros que son legibles para todo el mundo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La idea de
</span><span style="font-size: 10pt"><tt>none</tt></span><span style="font-size: 10pt">
es análoga al usuario anonymous de los servicios FTP.
En Plan 9 además, los servidores FTP invitados son confinados dentro de un espacio de nombres especial restringido.
Esto desconecta a los usuarios invitados de los programas del sistema, como los contenidos de
</span><span style="font-size: 10pt"><tt>/bin</tt></span><span style="font-size: 10pt">,
pero posibilita el poner ficheros locales disponibles para ellos, enlazándolos explicitamente en el espacio.
Un espacio de nombres restringido es más seguro que la técnica usual de exportar un arbol de directorios ad hoc; el resultado es una especie de jaula alrededor de los usuarios no fiables.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>El comando CPU y la autenticación con proxy
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Cuando se hace una llamada a un servidor CPU para un usuario, pongamos Peter, la idea es que Peter pueda ejecutar procesos con su propia autoridad. Para implementar esta propiedad, el servidor de CPU hace lo siguiente cuando se recibe la llamada.
Este proceso cambia al usuario 
</span><span style="font-size: 10pt"><tt>none</tt></span><span style="font-size: 10pt">
para evitar regalar permisos si es comprometido. Luego realiza el protocolo de autenticación para verificar que el usuario que llama es realmente Peter, y para probar a Peter que la máquina también es de fiar.
Finalmente, reengancha con todos los servidores de ficheros relevantes usando el protocolo de autenticación para identificarse a sí mismo como Peter.
En este caso, el servidor de CPU es un cliente del servidor de ficheros, y realiza la parte del intercambio de autenticación del cliente en nombre de Peter.
El servidor de autenticación le dará al proceso tickets para realizar esto solamente si al usuario administrativo del servidor de CPU se le permite 
</span><span style="font-size: 10pt"><i>hablar en nombre de </i></span><span style="font-size: 10pt">
Peter.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">La relación 
</span><span style="font-size: 10pt"><i>habla en nombre de</i></span><span style="font-size: 10pt">
[LABW91] se mantiene en una tabla en el servidor de autenticación.
Para simplificar la gestión de usuarios trabajando en distintos usuarios de autenticación, tambien contiene los mapeos entre nombres de usuarios en diferentes dominios, por ejemplo, si el usuario
</span><span style="font-size: 10pt"><tt>rtm</tt></span><span style="font-size: 10pt">
en un dominio es la misma persona que el usuario
</span><span style="font-size: 10pt"><tt>rtmorris</tt></span><span style="font-size: 10pt">
en otro.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Permisos de fichero
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una de las ventajas de la construcción de servicios como sistemas de ficheros es que la solución a los problemas de posesión y permisos viene dada naturalmente.
Igual que en UNIX, cada fichero o directorio tiene permisos separados de lectura, escritura y búsquda/ejecución para el dueño del fichero, el grupo del fichero o para el resto.
La idea de grupo es inusual: cualquier nombre de usuario es un nombre de grupo en potencia.
Un grupo es solo un usuario con una lista de otros usuarios en su grupo.
La diferencia es convencional: la mayor parte de la gente tiene nombres de usuario sin miembros en el grupo, mientras que los grupos tienen largas listas de nombres de usuario.
Por ejemplo, el grupo
</span><span style="font-size: 10pt"><tt>sys</tt></span><span style="font-size: 10pt">
agrupa tradicionalmenta a todos los programadores del sistema, y los ficheros del sistema son accesibles por el grupo
</span><span style="font-size: 10pt"><tt>sys</tt></span><span style="font-size: 10pt">.
Considérese la siguiente base de datos de usuarios almacenada en un servidor:
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Los ficheros regulares son poseidos por el usuario que los crea. El nombre del grupo se hereda del directorio que guarda el nuevo fichero. Los dispositivos se tratan especialmente: el nucleo puede arreglar la posesión y los permisos del fichero para adecuarlos al usuario que está accediendo al mismo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Un buen ejemplo de la generalización que esto ofrece son los ficheros de proceso, los cuales son poseidos y protegidos para lectura por el dueño del proceso. Si el dueño quiere dejar a alguien acceso a la memoria del proceso, por ejemplo para dejar que el autor de un programa realice el debugging de una imagen rota, basta con aplicar el comando estandar 
</span><span style="font-size: 10pt"><tt>chmod</tt></span><span style="font-size: 10pt">
a los ficheros del proceso.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Otra aplicación habitual de los permisos de ficheros es el sistema de volcados, que no solamente es servido por el mismo servidor de ficheros que los datos originales, sino que también es representado por la misma base de datos de usuarios.
Los ficheros del volcado siguien teniendo pués idéntica protección a los ficheros del sistema normal; si un fichero pertenece a
</span><span style="font-size: 10pt"><tt>pjw</tt></span><span style="font-size: 10pt">
y está protegido para lectura, una vez que está en el volcado sigue perteneciendo a 
</span><span style="font-size: 10pt"><tt>pjw</tt></span><span style="font-size: 10pt">
y protegido para lectura.
Además, puesto que el sistema de volcados es inmutable, el fichero no puede ser cambiado, y permanecerá para siempre protegido para lectura.
Los inconvenientes son que si el fichero es legible pero debería haber estado protegido, permanecerá legible para siempre, y que los nombres de usuario son difíciles de reutilizar. 
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Rendimiento
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Como simple medida del rendimiento del nucleo de Plan 9, hemos comparado el tiempo que se tarda en hacer algunas operaciones simples con él en un IRIX Release 5.3 de SGI, corriendo en una SGI Challenge M con un MIPS R4400 a 100 MHz con 1 megabyte de caché secundaria. 
El programa de test fué escrito en Alef, compilado con el mismo compilador, y ejecutado hardware idéntico, de modo que las únicas variables son el sistema operativo y las librerías.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El programa mide el tiempo que se tarda en hacer un cambio de contexto
(</span><span style="font-size: 10pt"><tt>rendezvous</tt></span><span style="font-size: 10pt">
en Plan 9,
</span><span style="font-size: 10pt"><tt>blockproc</tt></span><span style="font-size: 10pt">
en IRIX);
una llamada al sistema trivial
(</span><span style="font-size: 10pt"><tt>rfork(0)</tt></span><span style="font-size: 10pt">
y
</span><span style="font-size: 10pt"><tt>nap(0)</tt></span><span style="font-size: 10pt">);
y una bifurcación ligera 
(</span><span style="font-size: 10pt"><tt>rfork(RFPROC)</tt></span><span style="font-size: 10pt">
y
</span><span style="font-size: 10pt"><tt>sproc(PR_SFDS|PR_SADDR)</tt></span><span style="font-size: 10pt">).
También mide el tiempo de enviar un byte por un pipe desde un proceso a otro y el ????? throughput ?????? en un pipe entre dos procesos.
El resultado aparece en la Tabla 1.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<center><img src="91.png"></center>
</center>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: center;">
<span style="font-size: 10pt"><i>Tabla 1.  Comparación de rendimiento.</i></span></p>
<p style="margin-top: 0; margin-bottom: 0.02in"></p>

<p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aunque los tiempos de Plan 9 no son espectaculares, demuestran que el nucleo es competitivo con sistemas comerciales.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Discusión
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Plan 9 tiene un nucleo relativamente convencional, la novedad del sistema radica en las piezas que lo rodean y en la forma como interactúan. Cuando construimos Plan 9 consideramos todos los aspectos del sistema al mismo tiempo, resolviendo cada problema donde la solución encajaba mejor.
A veces una solución abarcaba varios componentes. Un ejemplo es el problema de la heterogeneidad de instrucciones entre arquitecturas, 
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">????????
que se resolvió por medio de compiladores (??????? diferentes caractéres de código ????????, codigo objeto portable), 
which is addressed by the compilers (different code characters, portable object code),
????????
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>

<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">el entorno
(</span><span style="font-size: 10pt"><tt>$cputype</tt></span><span style="font-size: 10pt">
y 
</span><span style="font-size: 10pt"><tt>$objtype</tt></span><span style="font-size: 10pt">),
el espacio de nombres
(enlaces a 
</span><span style="font-size: 10pt"><tt>/bin</tt></span><span style="font-size: 10pt">),
y otros componentes.
Algunas cuestiones podían resolverse en un solo lugar.
El mejor ejemplo es 9P, que centraliza el nombrado, acceso y autenticación.
9P es realmente el corazón del sistema; sería justo decir que el nucleo de Plan 9 es primordialmente un multiplexador de 9P.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">El enfoque de Plan 9 sobre los ficheros y los nombres es capital para su expresividad.
Particularmente en la computación distribuida, la forma en que se nombran las cosas tiene profunda influencia en el sistema [Nee89].
La combinación de espacios de nombres locales y convenciones globales para interconectar recursos en red evita la dificultadd e mantener un espacio de nombre global uniforme, mientras que nombrar todo como ficheros hace al sistema fácil de entender incluso para principiantes.
Considérese el sistema de volcados, cuyo uso es trivial cualquiera familiar con los sistemas jerárquicos de ficheros.
A un nivel más profundo, construir todos los recursos sobre un simple y uniforme interfaz facilita la 
?????????
interoperabilidad
?????????????
Un interfaz 9P exportado por un recurso, puede combinarse transparentemente 
con cualquier otra parte del sistema para crear aplicaciones inusuales; los detalles quedan ocultos.
Esto puede sonar &lsquo;orientado a objetos&rsquo; pero hay diferencias.
Primero, 9P define un conjunto fijo de &lsquo;métodos&rsquo;; no es un protocolo extensible.
Más importante, los ficheros están bien definidos y estudiados, y vienen ya con métodos familiares de acceso, nombrado, protección y trabajo en red.
Los objetos, a pesar de su generalidad, no vienen ya con esos atributos definidos. Reduciendo &lsquo;objeto&rsquo; a &rsquo;fichero&rsquo;, Plan 9 consigue bastante tecnología gratuitamente.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aún así, es posible llevar la idea de la computación basada en ficheros demasiado lejos. Convertir cada recurso del sistema en un sistema de ficheros es una metáfora, y se puede abusar de las metáforas. 
Un buen ejemplo de restricción es  
</span><span style="font-size: 10pt"><tt>/proc</tt></span><span style="font-size: 10pt">,
que es solamente la vista de un proceso, no su representación.
Para ejecutar procesos, sigue siendo necesario llamar a
</span><span style="font-size: 10pt"><tt>fork</tt></span><span style="font-size: 10pt">
y a
</span><span style="font-size: 10pt"><tt>exec</tt></span><span style="font-size: 10pt">
en lugar de hacer algo como 
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">&iquest;Qué haremos de forma diferente la próxima vez?
Algunos elementos de la implementación no son satisfactorios. El uso de streams para implementar interfaces de red en el nucleo permite que varios protocolos se conecten simultáneamente de forma dinámica, como enganchar el mismo driver de TTY a conexiones UCP, URP y IL, pero Plan 9 no hace uso de esta configurabilidad.
(Ha sido explotado, sin embargo, en la investigación de sistemas UNIX, para la que las streams fueron inventadas.)
Reemplazar las streams por colas estáticas de E/S hubiese simplificado el código y lo hubiese hecho más veloz.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aunque el nucleo principal de Plan 9 es portable entre muchas máquinas, el servidor de ficheros está implementado por separado. Esto ha causado varios problemas: drivers que deben ser escritos dos veces, errores que han de corregirse dos veces, y una peor portabilidad del código del sistema de ficheros.
La solución es facil: el nucleo del servidor de ficheros debe mantenerse como una variante del sistema operativo, sin procesos de usuario y con procesos especiales para implementar servicio de ficheros.
Otra mejora al sistema de ficheros sería un cambio de la estructura interna.
El jukebox WORM es la pieza de hardware menos fiable, pero debido a que guarda los metadatos del sistema de ficheros, deben estar presentes para servir ficheros.
El sistema puede ser reestructurado de modo que el WORM sea un dispositivo de backup solamente, con el sistema de ficheros real residiendo en discos magnéticos.
Esto no requeriría ningun cambio en el interfaz externo.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aunque Plan 9 tiene espacios de nombre pro proceso, no tiene un mecanismo para dar la descripción del espacio de nombres de un proceso a otro, excepto por herencia.
El comando
</span><span style="font-size: 10pt"><tt>cpu</tt></span><span style="font-size: 10pt">
, por ejemplo, no puede en general reproducir el espacio de nombres del terminal; solo puede reinterpretar el perfil de login del usuario y hacer sustituciones para cosas como el nombre del directorio de binarios.
Esto hace que se pierda cualquier modificación local hecha antes de ejecutar
</span><span style="font-size: 10pt"><tt>cpu</tt></span><span style="font-size: 10pt">.
En su lugar, debe ser posible capturar el espacio de nombres de la terminal y transmitir su descripción a un proceso remoto.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Aparte de estos problemas, Plan 9 funciona bien. Ha madurado y se ha convertido en un sistema que soporta nuestra investigación, en lugar de ser el sujeto de la misma.
El nuevo trabajo experimental incluye desarrollar interfaces para redes más rápidas, cacheo de ficheros en el nucleo del cliente, encapsulación y exportación de espacios de nombres, y la posibilidad de reestablecer el estado del cliente después de una caída del servidor.
La atención está ahora puesta en usar el sistema para construir aplicaciones distribuidas.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.35in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt">Una razón del éxito de Plan 9 consiste en que nosotros lo usamos para nuestro trabajo diario, simplemente como una herramienta de investigación. El uso activo nos fuerza a encarar los problemas según surgen, y a adaptar el sistema para resolverlos.
A través de este proceso, Plan 9 ha llegado a ser un entorno de programación confortable y productivo, así como un vehículo para investigación de sistemas futuros.
</span></p><p style="margin-top: 0; margin-bottom: 0.17in"></p>
<p style="line-height: 1.2em; margin-left: 1.40in; text-indent: 0.40in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 10pt"><b>Referencias
</b></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[9man] </span><span style="font-size: 9pt"><i>Plan 9 Programmer&rsquo;s Manual,
Volume 1,
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories,
Murray Hill, NJ,
1995.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[ANSIC]    </span><span style="font-size: 9pt"><i>American National Standard for Information Systems -
Programming Language C</i></span><span style="font-size: 9pt">, American National Standards Institute, Inc.,
New York, 1990.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Duff90]   Tom Duff, &lsquo;&lsquo;Rc - A Shell for Plan 9 and UNIX systems&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Proc. of the Summer 1990 UKUUG Conf.,
</i></span><span style="font-size: 9pt">London, July, 1990, pp. 21-33, reprinted, in a different form, in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Fra80]    A.G. Fraser,
&lsquo;&lsquo;Datakit - A Modular Network for Synchronous and Asynchronous Traffic&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Proc. Int. Conf. on Commun.,
</i></span><span style="font-size: 9pt">June 1980, Boston, MA.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[FSSUTF]   </span><span style="font-size: 9pt"><i>File System Safe UCS Transformation Format (FSS-UTF),
</i></span><span style="font-size: 9pt">X/Open Preliminary Specification, 1993.
ISO designation is
ISO/IEC JTC1/SC2/WG2 N 1036, dated 1994-08-01.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[ISO10646]     ISO/IEC DIS 10646-1:1993
</span><span style="font-size: 9pt"><i>Information technology -
Universal Multiple-Octet Coded Character Set (UCS) &mdash;
Part 1: Architecture and Basic Multilingual Plane.
</i></span><span style="font-size: 9pt"></span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Kill84]   T.J. Killian,
&lsquo;&lsquo;Processes as Files&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX Summer 1984 Conf. Proc.,
</i></span><span style="font-size: 9pt">June 1984, Salt Lake City, UT.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[LABW91]   Butler Lampson,
Martín Abadi,
Michael Burrows, and
Edward Wobber,
&lsquo;&lsquo;Authentication in Distributed Systems: Theory and Practice&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Proc. 13th ACM Symp. on Op. Sys. Princ.,
</i></span><span style="font-size: 9pt">Asilomar, 1991,
pp. 165-182.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[MBSS87]   S. P. Miller,
B. C. Neumann,
J. I. Schiller, and
J. H. Saltzer,
&lsquo;&lsquo;Kerberos Authentication and Authorization System&rsquo;&rsquo;,
Massachusetts Institute of Technology,
1987.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[NBS77]    National Bureau of Standards (U.S.),
</span><span style="font-size: 9pt"><i>Federal Information Processing Standard 46,
</i></span><span style="font-size: 9pt">National Technical Information Service, Springfield, VA, 1977.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Nee89]    R. Needham, &lsquo;&lsquo;Names&rsquo;&rsquo;, in
</span><span style="font-size: 9pt"><i>Distributed systems,
</i></span><span style="font-size: 9pt">S. Mullender, ed.,
Addison Wesley, 1989
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[NeHe82]   R.M. Needham and A.J. Herbert,
</span><span style="font-size: 9pt"><i>The Cambridge Distributed Computing System,
</i></span><span style="font-size: 9pt">Addison-Wesley, London, 1982
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Neu92]    B. Clifford Neuman,
&lsquo;&lsquo;The Prospero File System&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX File Systems Workshop Proc.,
</i></span><span style="font-size: 9pt">Ann Arbor, 1992, pp. 13-28.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[OCDNW88]  John Ousterhout, Andrew Cherenson, Fred Douglis, Mike Nelson, and Brent Welch,
&lsquo;&lsquo;The Sprite Network Operating System&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>IEEE Computer,
</i></span><span style="font-size: 9pt">21(2), 23-38, Feb. 1988.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Pike87]   Rob Pike, &lsquo;&lsquo;The Text Editor </span><span style="font-size: 9pt"><tt>sam</tt></span><span style="font-size: 9pt">&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Software - Practice and Experience,
</i></span><span style="font-size: 9pt">Nov 1987, </span><span style="font-size: 9pt"><b>17</b></span><span style="font-size: 9pt">(11), pp. 813-845; reprinted in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Pike91]   Rob Pike, &lsquo;&lsquo;8&frac12;, the Plan 9 Window System&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX Summer Conf. Proc.,
</i></span><span style="font-size: 9pt">Nashville, June, 1991, pp. 257-265,
reprinted in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Pike93]   Rob Pike and Ken Thompson, &lsquo;&lsquo;Hello World or ???????? ?????????&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX Winter Conf. Proc.,
</i></span><span style="font-size: 9pt">San Diego, 1993, pp. 43-50,
reprinted in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Pike94]   Rob Pike,
&lsquo;&lsquo;Acme: A User Interface for Programmers&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX Proc. of the Winter 1994 Conf.,
</i></span><span style="font-size: 9pt">San Francisco, CA,
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Pike95]   Rob Pike,
&lsquo;&lsquo;How to Use the Plan 9 C Compiler&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Plan 9 Programmer&rsquo;s Manual,
Volume 2,
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories,
Murray Hill, NJ,
1995.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[POSIX]    </span><span style="font-size: 9pt"><i>Information Technology&mdash;Portable Operating
System Interface (POSIX) Part 1:
System Application Program Interface (API)
[C Language],
</i></span><span style="font-size: 9pt">IEEE, New York, 1990.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[PPTTW93]  Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom, &lsquo;&lsquo;The Use of Name Spaces in Plan 9&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Op. Sys. Rev.,
</i></span><span style="font-size: 9pt">Vol. 27, No. 2, April 1993, pp. 72-76,
reprinted in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Presotto] Dave Presotto,
&lsquo;&lsquo;Multiprocessor Streams for Plan 9&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>UKUUG Summer 1990 Conf. Proc.,
</i></span><span style="font-size: 9pt">July 1990, pp. 11-19.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[PrWi93]   Dave Presotto and Phil Winterbottom,
&lsquo;&lsquo;The Organization of Networks in Plan 9&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>USENIX Proc. of the Winter 1993 Conf.,
</i></span><span style="font-size: 9pt">San Diego, CA,
pp. 43-50,
reprinted in this volume.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[PrWi95]   Dave Presotto and Phil Winterbottom,
&lsquo;&lsquo;The IL Protocol&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Plan 9 Programmer&rsquo;s Manual,
Volume 2,
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories,
Murray Hill, NJ,
1995.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[RFC768]   J. Postel, RFC768,
</span><span style="font-size: 9pt"><i>User Datagram Protocol,</i></span><span style="font-size: 9pt">
</span><span style="font-size: 9pt"><i>DARPA Internet Program Protocol Specification,</i></span><span style="font-size: 9pt">
August 1980.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[RFC793]   RFC793,
</span><span style="font-size: 9pt"><i>Transmission Control Protocol,</i></span><span style="font-size: 9pt">
</span><span style="font-size: 9pt"><i>DARPA Internet Program Protocol Specification,</i></span><span style="font-size: 9pt">
September 1981.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Rao91]    Herman Chung-Hwa Rao,
</span><span style="font-size: 9pt"><i>The Jade File System,
</i></span><span style="font-size: 9pt">(Ph. D. Dissertation),
Dept. of Comp. Sci,
University of Arizona,
TR 91-18.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Rit84]    D.M. Ritchie,
&lsquo;&lsquo;A Stream Input-Output System&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>AT&amp;T Bell Laboratories Technical Journal,
</i></span><span style="font-size: 9pt"><b>63</b></span><span style="font-size: 9pt">(8), October, 1984.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Tric95]   Howard Trickey,
&lsquo;&lsquo;APE &mdash; The ANSI/POSIX Environment&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Plan 9 Programmer&rsquo;s Manual,
Volume 2,
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories,
Murray Hill, NJ,
1995.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Unicode]  </span><span style="font-size: 9pt"><i>The Unicode Standard,
Worldwide Character Encoding,
Version 1.0, Volume 1,
</i></span><span style="font-size: 9pt">The Unicode Consortium,
Addison Wesley,
New York,
1991.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[UNIX85]   </span><span style="font-size: 9pt"><i>UNIX Time-Sharing System Programmer&rsquo;s Manual,
Research Version, Eighth Edition, Volume 1.
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories, Murray Hill, NJ, 1985.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Welc94]   Brent Welch,
&lsquo;&lsquo;A Comparison of Three Distributed File System Architectures: Vnode, Sprite, and Plan 9&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Computing Systems,
</i></span><span style="font-size: 9pt">7(2), pp. 175-199, Spring, 1994.
</span></p><p style="margin-top: 0; margin-bottom: 0.05in"></p>
<p style="line-height: 1.0em; margin-left: 1.56in; text-indent: 0.00in; margin-right: 1.00in; margin-top: 0; margin-bottom: 0; text-align: justify;">
<span style="font-size: 9pt">[Wint95]   Phil Winterbottom,
&lsquo;&lsquo;Alef Language Reference Manual&rsquo;&rsquo;,
</span><span style="font-size: 9pt"><i>Plan 9 Programmer&rsquo;s Manual,
Volume 2,
</i></span><span style="font-size: 9pt">AT&amp;T Bell Laboratories,
Murray Hill, NJ,
1995.
</span></p><p style="margin-top: 0; margin-bottom: 0.50in"></p>




</div>

<div id="footer">
<br class="doNotDisplay doNotPrint" />

<div class="left"><a href="http://werc.cat-v.org/">Powered by werc</a></div>

<div class="right">
<form action="http://www.google.com/cse" id="cse-search-box" style="display: inline">
  <div style="display: inline">
    <input type="hidden" name="cx" value="partner-pub-2060328396151526:ea9sar-xttn" />
    <input type="hidden" name="ie" value="UTF-8" />
    <input type="text" name="q" size="32" />
    <input type="submit" name="sa" value="Search" />
  </div>
</form>
<script type="text/javascript" src="http://www.google.com/coop/cse/brand?form=cse-search-box&lang=en"></script></div>


<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-1220719-1");
pageTracker._setDomainName("cat-v.org");
pageTracker._trackPageview();

var pageTracker2 = _gat._getTracker("UA-1220719-12");
pageTracker2._trackPageview();
} catch(err) {}</script>
</div>
</body></html>
